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Preface 


This  document  consists  of  a  collection  of  informal  papers  and  briefings  bearing  on  the 
subject  of  federated  architecture.  The  papers  and  briefings  were  prepared  in  support  of 
the  Department  of  Defense’s  substantial  effort  to  transform  and  modernize  the  Business 
Mission  Area,  now  the  Defense  Business  Transformation  (DBT),  formerly  the  Business 
Management  Modernization  Program  (BMMP),  by  the  Institute  for  Defense  Analyses 
under  task  order  BF-5-2105,  Independent  Assessment  of  Conflict  of  Interest  and  Other 
Issues  in  the  Business  Enterprise  Architecture  (BEA).  Following  a  short  Introduction,  a 
Background  section  and  a  short  exposition  on  the  Federated  Approach,  the  papers  and 
briefings  are  included,  each  preceded  by  a  short  description  of  the  circumstances  under 
which  each  paper  was  developed  and  delivered.  The  papers  themselves  appear  exactly  as 
they  were  delivered  at  the  time,  without  any  further  editing. 


We  thank  Dr.  Paul  Tibbits,  Director,  Business  Management  Modernization  Program 
(BMMP),  with  a  tenure  spanning  much  of  the  period  that  the  material  was  developed,  for 
his  support  of  federation  concepts  and  also  Ms  Marilyn  Fleming  and  Mr.  Brian 
Wilczynski,  successively  the  chief  architects  of  the  BEA  during  that  period,  for  their 
support. 


This  document  was  reviewed  by  IDA  Research  Staff  Members,  Dr.  L.  Roger  Mason,  Jr. 
and  Dr.  Francisco  Loaiza-Lemos. 
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Introduction 


The  office  of  the  Under  Secretary  of  Defense  (Comptroller)  (USD  (C))  tasked  IDA  to 
support  the  Business  Management  Modernization  Program  (BMMP)  office  starting  in 
December  2002.  IDA  tasking  assignments  initially  focused  on  activities  of  monitoring 
and  identifying  potential  Organizational  Conflict  of  Interest  risks  that  might  impact  the 
program  or  participating  contractors.  However,  the  primary  focus  of  activities  was 
quickly  broadened  to  include  a  wide  range  of  technical  monitoring  and  assessment 
responsibilities.  In  this  latter  capacity,  IDA  starting  in  mid-2003,  began  promoting  the 
concept  of  a  federated  architecture.  A  number  of  IDA  point  papers,  draft  documents, 
and  briefings  on  this  concept  have  resulted.  The  purpose  of  this  document  is  to  present 
a  time-ordered  compilation  of  these  contributions,  illustrating  the  initial  ideas  as 
presented  and  continuing  development  and  maturation  of  the  approach  over  the  two 
year  span  covered.  Note  that  most  of  these  papers  were  delivered,  before  the  October 
7,  2005  establishment  of  the  Business  Transformation  Agency  (BTA),  which  now  has 
responsibility  for  the  Defense  Business  Transformation. 

Since  that  time,  the  Director,  Architecture  and  Interoperability,  ASD  Nil,  has  chartered 
the  Federated  Joint  Architectures  Working  Group  (FJAWG)  which  is  developing  a 
strategy  for  federation  of  the  GIG  Architecture.  Consequently,  some  of  the  views 
expressed  in  this  document  may  not  be  consistent  with  current  DOD  CIO  guidance  on 
this  topic. 
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Background 


The  BMMP  had  been  established  by  the  Secretary  of  Defense  in  July  2001,  initially  as 
an  important  initiative  toward  providing  the  Department  with  relevant,  reliable,  and 
timely  financial  information  to  facilitate  effective  decision  making.1  Over  time  this  has 
come  to  be  understood  more  generally  as  an  approach  to  transform  all  the  business 
practices  of  the  Department  to  best  serve  the  warfighter  as  well  as  to  provide  clean 
auditable  financial  data.  Thus  the  objective  of  the  BMMP  is  to  “ensure  that  the 
Department’s  Business  Mission  Area  (BMA)  rapidly  delivers  to  our  warfighters  the 
right  capabilities,  resources  and  materiel:  What  they  need,  where  they  need  it,  when 
they  need  it,  anywhere  in  the  world.  In  order  to  cost-effectively  and  prudently  meet 
these  requirements,  DoD’s  current  business  and  financial  management  infrastructure — 
processes,  systems,  and  data  standards — are  being  transformed.  DoD’s  business 
transformation  is  focused  on  providing  end-to-end  integration  of  operations  in  support 
of  missions  in  times  of  peace  and  war.  From  a  financial  accountability  standpoint, 
transformation  will  provide  accurate,  reliable,  and  timely  financial  information, 
affirmed  by  clean  financial  audit  opinions.”2 

Such  a  transformation  demands,  by  both  good  practices  and  Department  policy,  a 
disciplined  process  to  develop  the  necessary  plan  of  approach.  The  primary 
components  of  this  process  are  (i)  the  development  of  an  architecture  defining  the 
“blueprint”  for  the  entities  to  be  transformed  and  (ii)  a  transformation  plan  delineating 
the  control  and  the  “time-line”  for  executing  the  blueprint. 

An  initial  release  of  these  products  was  delivered  in  April  2003,  on  the  schedule  that 
had  been  set.  The  products  were  by  no  means  complete,  but  considering  the  magnitude 
of  the  challenge  and  the  short  time  that  the  initiative  had  been  in  existence,  it  was  quite 
an  accomplishment. 

The  effort  to  produce  a  more  refined  version  of  these  products,  in  what  must  be  a 
continuing  evolution  “spiral  development”  approach,  started  immediately  after  the 
initial  delivery.  But  with  the  early  experience  it  became  quite  evident  that  in  so  large 
and  complex  an  organizational  structure  as  the  DoD,  along  with  multiple  and  varied 
missions  and  cultures,  that  to  successfully  build  an  architecture  that  could  lead  to  a 
successful  transformation  of  the  Department’s  business  practices  required  a  more 
detailed  understanding  of  how  to  organize  the  design  effort. 


1  Initially  the  initiative  was  designated  the  Financial  Management  Modernization  Program  (FMMP).  The 
name  was  changed  to  BMMP,  when  it  became  clear  that  the  scope  of  the  modernization  transformation  was 
a  broader  business  transformation. 

2  http://www.dod.mil/dbt/mission  whv.html 
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Initially  there  were  multiple  ideas  as  to  how  this  should  be  accomplished.  The 
requirement  was  to  produce  a  Business  Enterprise  Architecture  (BEA),  which  could  (a) 
satisfy  the  needs  of  the  five  Core  Business  Mission  (CBM)  areas  ( —  initially  these 
were  six  Domains),  (b)  be  implementable  by  the  various  DoD  Components,  (c)  be 
interoperable  amongst  the  various  entities,  and  (d)  be  consistent  with  the  rules  imposed 
by  the  Global  Information  Grid  (GIG),  the  Federal  Enterprise  Architecture  (FEA) 
Reference  Modal,  and  by  Congress. 
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Federated  Approach 


Starting  early  in  2004,  a  number  of  serious  approaches  for  attacking  the  problem  were 
proposed.  In  abstract  terms,  the  two  polar  extremes  of  these  various  ideas  could  be 
characterized  as  (i)  a  single  Enterprise  Resource  Program  (ERP)  across  the 
Department,  and  (ii)  a  federated  approach.  Of  course  between  these  two  limits  there 
are  many  possible  variants.  The  federated  approach  was  introduced  early  in  2004  by 
IDA  (as  well  as  by  some  others),  and  EDA  has  championed  the  federated  approach 
since  then.  Given  the  complexity  of  the  Department,  it  appeared  to  EDA  that  a  single 
ERP  approach,  or  anything  near  a  unified  ERP  was  unlikely  to  be  workable.  During  the 
past  year,  the  federated  approach  has  been  adopted  for  the  BMA  transformation. 

As  required  by  the  National  Defense  Authorization  Act  of  2005,  on  September  30, 
2005  and  on  time  the  current  BEA,  designated  BEA  3.0  was  delivered  to  Congress. 
“The  BEA  3.0  provides  the  architectural  framework  for  an  information  infrastructure 
for  DoD,  including  business  rules,  requirements,  data  standards,  system  interface 
requirements,  and  the  depiction  of  policies  and  procedures.” 

BEA  3.0  was  developed  under  the  DoD  Tiered  Accountability  concept  reflecting  the 
Business  Enterprise  Priorities  (BEP)  within  the  Core  Business  Mission  areas.  Through 
this  concept,  a  DoD  Component  is  responsible  for  defining  an  enterprise  architecture 
associated  with  their  own  tier  of  responsibility,  while  complying  with  the  policy  and 
BEA  at  the  DoD  Enterprise-level.  Within  the  DoD  Business  Mission  Area,  the  BEA 
and  Component  Enterprise  Architectures  provide  the  required  guidance  as  part  of  a 
federated  approach.  Additionally,  the  BEA  is  federated  with  the  Federal  Enterprise 
Architecture  and  other  external  architectures.  Subsequent  releases  of  the  BEA  will 
continue  to  use  a  federated  approach  to  define  and  enforce  the  seams  or  interfaces 
between  each  tier,  thus  ensuring  interoperability  and  information  flow  to  support 
decision  making  at  the  appropriate  level. 

This  federated  approach  for  the  BEA  is  markedly  different  from  earlier  attempts  to 
manage  a  single,  centralized  architecture  spanning  the  full  range  of  functions  and 
activities  of  the  Department.  This  transformation  effort  focuses  on  providing  tangible 
outcomes  for  a  limited  set  of  priorities,  and  on  developing  architectures  that  are  linked, 
realistic,  and  actionable.  The  current  scope,  defined  by  the  six  BEPs,  permits  the  BEA 
to  develop  and  expand  in  a  controlled  and  consistent  fashion.  The  framework  and 
architecture  products  developed  for  these  BEPs  may  be  extended  to  all  defense 
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business  systems  and  initiatives.  As  new  priorities  are  identified  and  existing  priorities 
mature,  DoD  may  refine  and  extend  the  BEA  to  address  the  required  capabilities.”3 

Over  the  past  two  years  IDA  has  provided  a  number  of  informal  papers  and  briefings 
for  the  senior  line  management  of  DBT  expounding  on  the  merits  of  the  federated 
approach.  This  document  assembles  a  collection  of  the  more  important  of  these  papers, 
in  a  time  ordered  sequence,  spanning  the  period  January  2004  through  January  2006. 
Note  that  the  focus  of  the  issues  under  discussion  has  changed  over  that  two  year 
period.  Initially,  the  focus  was  to  expound  on  the  merits  of  the  federated  approach  for 
the  problem  at  hand.  Now  that  there  is  widespread  embrace  of  the  federated  approach, 
IDA  has  been  encouraging  DBT  management  to  more  actively  embrace  and  to 
facilitate  its  application  in  the  instantiation  of  transitioned  business  systems  and 
enhanced  systems  interoperability.  To  accomplish  this  will  require  the  establishment 
of  new  federation  by-laws  and  concepts  of  operation.  In  addition  to  a  wide  range  of 
governance  issues  that  must  be  addressed,  specific  technical  areas  that  need  to  be 
addressed  include  definitions  of  processes  and  process  exchange  protocols,  and  data 
and  metadata  and  data  exchange  specifications.  The  establishment  of  standards, 
agreements,  taxonomies,  etc.  are  crucial  to  the  attainment  of  the  goal  of  transparent 
federated  interoperability  to  best  support  the  warfighter. 

Since  very  little  has  been  yet  committed  amongst  the  Components  in  addressing  these 
matters,  there  is  a  currently  a  time  window  of  opportunity  to  coalesce  the  Department’s 
thinking  and  action.  If  action  is  not  started  soon  it  will  be  much  more  difficult  to 
achieve  coherence  and  achieve  the  BMA  transformation  goals.  In  IDA’s  view,  the 
thinking  across  the  Department  has  not  yet  matured  to  a  consistent  understanding  on 
this  matter.  The  more  recent  papers  in  the  collection  begin  to  address  this  issue. 


3  http://www.dod.mil/dbt/tools  bea.html 
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BEA  Architectural  Terms  Tutorial 


This  paper,  with  a  goal  of  clarifying  the  use  of  architectural  terms,  was  distributed  in 
several  minor  revisions  to  a  number  of  senior  BMMP  line  managers,  including  the 
BEA  chief  architect,  starting  in  January  2004.  Note  that  the  last  section  on  page  12 
introduces  the  federation  concept. 
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IDA  Revised  3/18/04 


BEA  ARCHITECTURAL  TERMS  TUTORIAL 

Ambiguity  in  the  Term  “Architecture” 

Relevant  to  the  BEA  context,  the  term  “architecture”  can  be  used  two  ways:  One,  to  refer 
to  the  real  (material  or  physical)  configuration  of  (or  set  of  relationships  between)  the 
parts  of  a  machine  or  building  or  information  system.  Two,  to  refer  to  a  depiction  (a 
written  or  verbal  description,  a  drawing,  a  formal  schematic,  etc.)  of  the  configuration 
referred  to  in  the  first  sense  described  above.  An  architect,  in  the  process  of  designing  a 
building  (or  an  information  system),  generally  produces  drawings,  that  depict  the 
architecture  to  be  imbued  in  some  eventually  built  physical  building  or  information 
system.  The  set  of  drawings  is  not  the  physical  building  or  the  information  system,  but  its 
representation.  In  this  tutorial  the  two  definitions  will  be  explicitly  indicated  as 
architecture  (1)  and  architecture  (2). 


BEA  by  Analogy  to  the  New  World  Trade  Center 

In  this  description  references  to  the  World  Trade  Center  are  italicized  and  the  analogous 
BEA  entities  appear  in  square  brackets  [  ]. 

•  Daniel  Liebeskind  [ASD(NII)],  master  planner  [Nil]  for  the  World  Trade  Center  site 
[DoD],  has  responsibility  for  the  architecture  (1)  of  the  new  overall  multi-building 
complex  [GIG]. 

A  set  of  conceptual  drawings  [DoDAF  OV-1  diagrams — one  of  many 
architectural  products]  initiates  the  description  of  the  architectural  (2)  design — the 
“To  Be  architecture  (2).” 

As  the  design  of  the  various  buildings  [GIG  components]  proceeds,  details  of  the 
architecture  (1)  are  developed,  respecting  to  the  extent  possible  the  original 
concept,  but  also  conforming  to  the  requirements  of  the  WTC  owners  [Domains, 
their  Services,  and  Components]  and  to  the  legal  and  formal  and  informal 
building  codes  [legislative  and  DoD  policies  and  guidelines]. 

During  this  process  the  original  architectural  (1)  conceptual  design  will  evolve  to 
satisfy  all  these  conditions  and  will  be  documented  in  the  To  Be  architectural  (2) 
diagrams. 

•  Responsibility  for  the  architecture  (1)  of  the  Freedom  Tower  [BEA*],  one  of  the 
buildings,  was  assigned  to  David  Childs  of  the  architectural  firm  Skidmore  Owings  & 
Merrill  [BMSI], 

At  the  outset  the  architect  had  a  problem  with  Liebeskind’s  conceptual  design. 

This  problem  was  resolved  with  interaction  between  the  master  planner  [Nil]  and 
the  Freedom  Tower  architect  [BMSI],  resulting  in  a  set  of  compromises  based 
upon  functional  and  enterprise  requirements  [BPR  and  Governance].  This  in  turn 
resulted  in  some  changes  of  the  architecture  (1)  and  of  the  OV-1  diagrams 
describing  that  architecture  (2). 


*  BEA  here  means  the  Business  Enterprise  Architecture  (1). 
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•  As  the  various  tenants  of  the  Freedom  Tower  [Domains]  design  their  space  to 
optimize  their  functional  requirements  [BPR]  there  will  be  repeated  needs  for  the 
building  architect  [BMSI]  to  adjust  the  architecture  (1)  in  consultation  with  each 
tenant  [Domains,  their  Services,  and  Components]  and  any  of  the  other  tenants  [other 
Domains,  their  Services,  and  Components]  that  may  be  affected  by  such  changes. 
The  building  architect  [BMSI]  will  also  have  to  assure  that  these  architectural  (1) 
adjustments  are  consistent  [Governance]  with  the  overall  Freedom  Tower 
architecture  (1)  [BEA]  and  with  the  complex  master  plan  [GIG].  Evolving 
requirements  may  result  in  changes  to  the  complex  master  plan  [GIG]  or  to  the 
Freedom  Tower  architecture  (1)  [BEA]  or  the  requirements  may  have  to  be  modified 
to  accommodate  either  or  both  of  these  overarching  plans. 

-  This  process  is  iterative  as  the  details  of  the  various  tenant  architectures  (1)  are 
further  developed. 

-  Indeed,  the  process  continues  as  the  implementation  of  the  design  proceeds. 

The  process  also  continues  into  the  maintenance  period  once  the  implementation 
is  completed  to  accommodate  to  new  technologies  as  they  become  available  and 
to  meet  new  requirements  as  they  develop  in  the  future. 


•  Note  that  during  the  design  of  the  Freedom  Tower  architecture  (1)  [BEA], 
compromises  at  multiple  levels  are  negotiated  between  the  several  layers  of 
architectural  authority  within  the  enterprise  architecture  (1)  governance  structure  to 
accommodate  the  requirements  and  preferences  of  all  the  stakeholders. 

Configuration  management  of  both  the  architecture  (1)  and  its  architectural  (2) 
description  remains  the  responsibility  of  the  Freedom  Tower  architect  [BMSI]. 
Configuration  management  of  each  of  the  tenant  [Domains,  Services  and 
Components]  architectures  (1)  and  their  architectural  (2)  descriptions  is  the 
responsibility  of  each  of  the  respective  tenants  [Domains,  Services  and 
Components]. 


•  The  story  above  pertains  to  the  architecture  (1 )  of  the  Freedom  Tower  [BEA]  within 
the  larger  World  Trade  Center  [GIG]. 

The  description  of  that  architecture  (1)  [BEA]  is  given  in  numerous  architectural 
(2) products  [DoDAF  conforming  architectural  (2)  products]. 

Unfortunately  the  description  of  the  BEA  is  also  frequently  referred  to  as  the 
BEA.  causing  unnecessary  confusion.  To  distinguish  between  the  architecture  (1) 
and  a  description  of  the  architecture  (2),  here  we  will  use  DoDAF  BEA  to  mean 
the  description  of  the  BEA  to  distinguish  that  description  from  the  actual  BEA. 

The  one  fundamental  requirement  is  that  as  the  BEA  evolves  within  the  rules  of 
the  Governance  process,  the  DoDAF  BEA  must  be  updated  to  correctly  represent 
the  actual  BEA. 
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Instantiations  into  functional  products  (business  applications)  by  the  Domains,  the 
Services  and  Components  in  software/hardware  conforming  to  the  BEA  might  be 
called  “BEA  conforming  applications.” 

Some  Additional  Comments  on  the  BEA 

•  To  facilitate  the  generation  of  the  DoDAF  BEA  one  of  several  DoDAF  conforming 
tools  may  be  used. 

It  is  incumbent  on  BMSI  to  maintain  an  up  to  date  repository  of  the  DoDAF  BEA 
(at  all  levels)  accessible  at  all  levels  by  at  least  one  tool. 

Consistent  with  the  current  Nil  position,  any  DoDAF  architectural  description 
built  with  any  tool  that  conforms  to  the  DoDAF  should  be  transformable,  using 
appropriate  middleware,  into  a  form  accessible  to  any  other  such  tool.  (This  issue 
is  still  under  study  by  NIL) 

Consequently,  a  Domain,  Service  or  a  Component  may  use  any  tool  that  meets  the 
DoDAF  requirement  in  order  to  represent  its  local  architecture  (1). 


•  Different  stakeholders  have  different  needs  in  viewing  the  BEA. 

All  views  are  derived  from  the  BEA,  documented  in  the  DoDAF  BEA. 

The  stakeholders  include  a  very  wide  range  of  participants,  each  with  interests 
requiring  their  unique  views,  including: 

■  Functional  users  at  all  levels 

■  Functional  managers  at  all  levels 

■  Program  managers  at  all  levels 

■  Implemented  of  all  implementation  components 

■  Maintenance  personnel 

■  Designers  of  the  next  evolutionary  step 

■  Cross  Domain  Integration  contractor(s) 


•  To  facilitate  the  expeditious  instantiation  of  the  Freedom  Tower  architecture  (1) 
[BEA]  an  execution  approach  could  be  to  organize  the  effort  into  several  Increments. 
Each  of  the  Increments  provides  a  subset  of  the  required  enterprise  functions.  The 
various  detailed  systems  architecture  (2)  designs  and  contractors  to  implement  the 
architecture  (1)  for  each  of  the  functions  are  provided  by  the  functional  entity 
organizations  [Components].  In  all  cases  the  overall  Freedom  Tower  architecture  (2) 
[BEA]  defines  the  enterprise  approach  for  the  various  systems  architecture  (2) 
designs  and  architecture  (1)  implementations. 

The  first  Increment  might  be  for  contractual  commitments  for  the  Freedom  Tower 
shell  structure  including  its  utility  infrastructure  and  finished  space  only  for 
occupants  to  establish  a  set  of  initial  functions  [Unqualified  Audit  Opinion  and 
Total  Personnel  Visibility]. 

Increments  2  and  3  (or  more)  would  cover  finishing  customer  space  for  the  other 
tenants  [Domains;  stakeholders]  providing  additional  functions  in  two  (or  more) 
groups. 
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-  Note  that  each  Increment  may  be  divided  into  three  phases: 

■  Architecture  (2)  development  and  transition  planning  including  initial  BPR 
and  BPM  activities 

■  Systems  level  BPR  and  BPM,  acquisition  and  implementation  of  the 
architecture  (1) 

■  Sustainment  and  continuous  improvement 

-  Note  that  at  each  step  in  the  described  activities,  changes  may  be  required  in 

previously  built  Increments  to  accommodate  other  activities  or  new  capabilities. 

■  The  governance  process  assures  that  this  occurs  in  an  orderly  and  effective 
manner. 

■  This  is  part  of  the  healthy  evolution  that  an  enterprise  architecture  enables. 


•  Finally,  what  is  described  here  is  properly  called  a  “federation.” 

The  GIG  itself  federates  the  Warfighting,  National  Intelligence,  and  Business 
Enterprise  Mission  areas. 

-  The  federation  is  possible  because  the  GIG  defines  the  Technical  Infrastructure 
(and  the  National  Intelligence  Technical  Infrastructure),  including  the  Transport, 
Computing  Infrastructure,  and  Core  Enterprise  Services  Domains  at  the 
(controlled)  unclassified  and  at  the  several  classified  levels. 

Within  the  BEA  each  of  the  several  business  Domains  represent  federated  entities 
of  the  Business  Enterprise  Domain  conforming  to  the  rules  (as  adjudicated  within 
the  Governance  process)  of  the  BEA. 

And  within  each  business  Domain  the  various  functional  entities  in  each  of  the 
Services  and  Components  themselves  represent  federations  at  another  level,  all 
conforming  to  the  BEA. 

-  Note  that  the  roles  of  BMSI  and  the  several  Domains  are  different  in  the  three 
phases 

■  Phase  1  is  a  fully  shared  cooperative  activity  between  BMSI  and  the  several 
Domains. 

■  Execution  of  Phases  2  and  3  are  primarily  the  responsibility  of  the 
components  within  the  Domains. 

■  In  Phases  2  and  3  the  Domains  maintains  oversight  over  the  developments  by 
their  components  so  as  to  be  consistent  with  the  evolving  BEA  facilitates 
cross-Domain  consistency. 

■  In  Phases  2  and  3  BMSI  maintains  oversight  over  the  DoD-wide  BMMP  and 
maintains  the  evolving  DoD  DODAF  BEA  to  represent  the  “as  built”  BEA. 

The  BMMP  governance  structure  guaranties  the  orderly  resolution  of  problems 
that  may  arise. 
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BMMP  Strategic  Plan  Suggestions 


During  the  summer  of  2004,  the  BMMP  Director  had  assembled  a  group  of  about  six 
people  to  develop  a  “strategic  plan”  for  the  BMMP.  This  group  included  Drew  Miller, 
representing  the  Programming,  Planning,  Budgeting  and  Execution  (PPB&E)  Domain, 
and  Scott  Comes,  representing  the  Program  Assessment  and  Evaluation  (PA&E)  office. 
Miller  was  at  that  time  the  primary  proponent  of  an  ERP  approach,  while  Comes  was  one 
of  several  federation  proponents. 

The  briefing  included  here  summarized  the  arguments  of  the  two  proponents.  It  also 
included  in  the  last  four  slides  IDA’s  comments  on  the  two  sets  of  arguments. 
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BMMP  Background  (Outline  only  —  TBD) 


•  History 

-  Raison  d’etre 

-  Origin 

•  Business  Version  of  JV  2020 

•  BMMP 

-  Vision 

-  Mission 

-  Goals/Increment  Focus 

•  Accomplishments  to  Date 

-  Governance  structure 

-  BEA  2. 1  (soon  to  be  2.2) 

-  EBPM 

-  Maturation  of  Domain  Owners  -  BMSI  relationship 
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Important  Aspects  of  BMMP 

•  Enormously  Difficult 

-  Complex  and  dynamic  multi-facetted  “program”  spanning  all 
business  related  functions  of  the  DoD 

-  Is  “Joint”  both  horizontally  and  vertically 

-  Requires  changes  in  processes,  approaches  and  culture 

-  Executed  at  a  scale  not  here-to-for  encountered 

•  Very  Expensive 

-  Many  thousands  of  systems  to  be  upgraded/replaced 

-  Extant  systems  have  cost  in  the  tens  of  billions 

-  BMMP  instantiation  will  have  similar  costs 

•  Resulting  in  much  lower  O&M  costs 

•  Resulting  in  enormous  decreases  in  operating  personnel  costs 
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The  Stakeholder  Problem 

•  Stakeholder  Community  Permeates  DoD  from  Top  to  Bottom 

•  Primary  Active  Stakeholders  Include: 

-  BMSI:  Responsible  for  coordination,  maintenance,  evolutionary  direction 
and  oversight  of  the  program 

-  Domains:  Responsible  for  evolutionary  direction,  coordination,  and 
oversight  of  the  systems  and  applications  within  their  jurisdiction 

-  Components  (Services  and  Defense  Agencies): 

•  Through  the  PEOs  and  PMs  responsible  for  instantiation  of  the  systems  and 
products  for  the  transformation  to  the  “to  be”  architecture 

•  Within  the  components  the  CIOs  and  the  evolving  BMSI-like  entities  provide 
the  internal  coordination  and  interface  to  the  Domains  and  BMSI 

•  The  Problem:  A  well  articulated  and  widely  disseminated  enterprise 
level  description  of  the  major  functions  encompassed  by  the  BMMP, 
the  various  stakeholders,  and  what  roles  each  is  expected  to  take  in  the 
attainment  of  the  BMMP  goals  is  lacking 

-  Use  the  5  level  Baseline  graphic  to  guide  in  defining  the  boundaries  and 
responsibilities  of  stakeholders  within  each  Baseline  oval 


IDA 

7/14/04 

Important  BMSI  Responsibilities  —  In 
Coordination  with  Active  Stakeholders 

•  Define  and  widely  promulgate  the  BMMP  vision  and  achievable 
milestone  goals  with  strategies  to  attain  them  near,  mid,  and  long  term 

•  Define  and  respect  the  appropriate  roles  and  responsibilities  of  the 
various  stakeholders 

•  Facilitate  the  effective  interactions  between  the  stakeholder  entities, 
including  BMSI,  the  Domain  Owners,  and  the  Components  including 
the  PEOs,  PMs,  CIOs  and  BMSI-like  organizations 

•  Facilitate  the  assembly  of  the  systems  inventory  and  more  formal 
portfolios  by  the  Domains  and  Components 

-  Coordinate  Portfolio  Management  activities  of  the  Domains  and 
Components 

•  Develop  and  document  the  Enterprise  level  architecture  model  based 
on  the  end-to-end  “Enterprise  Business  Process  Model”  (EBPM) 
perspective 

-  Assemble  and  serve  as  the  repository  of  the  architecture  products 
developed  by  the  Domains  and  Components  for  the  business  functional 
systems  to  be  instantiated,  thereby  defining  the  BEA 
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Important  BMSI  Responsibilities  —  In 
Coordination  with  Active  Stakeholders  (Cont’d) 

•  Develop  a  transition  planning  template  and  an  enterprise 
level  transition  plan 

-  Assemble  the  Domain  and  Component  transition  plans  and  prepare 
a  Transition  Plan  document  spanning  the  BMMP  transition 
planning 

-  Update  the  Transition  Plan  document  as  the  BEA  evolves 

•  Coordinate  the  development  of  a  data  strategy  consistent 
with  the  GIG  Net-Centric  Data  Strategy 

-  Define  a  data  management  approach,  including  the  assignment  of 
“data  ownership,”  carrying  responsibility  for 

•  Accuracy  •  Integrity 

•  Reliability  •  Availability 

•  Access  control 
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Suggested  Key  Strategies 

1 .  Mature  and  apply  appropriate  Governance  process  at  all  organizational 
levels 

2.  Establish  an  enterprise  architecture  of  common  capabilities  and 
processes  crossing  Domains,  and  adopt  Domain  architecture  for  Domain 
unique  capabilities  and  processes 

3.  Establish  programmatic  and  budgeting  priorities  for  Business 
Transformation  within  an  integrated  PPBE  process  incorporating  PfM 

4.  Develop  a  data  strategy;  establish  unambiguous  data  definitions  and 
meta-data,  and  coordinate  mles  and  criteria  for  data  ownership,  use, 
modification,  persistence,  etc.  in  the  context  of  associated  communities- 
of-interest  processes 

5.  Develop  and  coordinate  Domain  and  Component  acquisition  and 
implementation  approaches  for  product  solutions;  collaborate  and 
incorporate  into  a  transformation  roadmap 
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Suggested  Elements  of  the  Governance 
Strategy 

•  Establish  additional  Governance  structures  modeled  after 
the  streamlined  processes  currently  in  place  for  issues 
between  Domains  and  BMSI 

-  Permit  quick  identification  and  analyses  of  issues 

-  Provide  for  cross  functional  issue  resolution  below  the  Domain 
level  (e.g..  Component,  Agency  or  Program) 

•  Develop  provisions  for  addressing  enterprise  issues  that: 

-  Cross  functional  areas  within  Components  or  Agencies 

-  Cross  functional  and  Domain  areas  between  Components  and 
Agencies 

-  Take  cognizance  of  OMB  and  FEA  requirements  being  addressed 
by  BMMP 
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Suggested  Elements  of 
Architectural  Development  Strategy 

•  Identify  and  differentiate  activities  that  must  be  performed  in  sequence  as  well 
as  those  that  may  be  performed  in  parallel 

•  Collaboratively  develop  plans  for  BMSI,  Domains,  and  Components 

-  Focus  on  common  capabilities  and  processes  crossing  Domains  as  appropriate 

-  Domains  responsible  for  their  unique  capabilities  and  processes 

•  Establish  pragmatic  WBS  and  workflow  leading  to  objectives 

-  Complete  end-to-end  process  modeling  (OV6c)and  requirements  tracing 

•  Next  iteration  of  the  OV7  will  focus  on  Financially  Relevant  data  objects, 
activities  will  then  need  to  establish  an  integrated  OV7  for  the  revised  OV6c 

•  Update  BEA  products  to  match  completed  OV6c  (e.g.,  OV6c->OV5,  SV4  . . .) 

-  Collect  and  put  in  common  format  all  Domain  BEA  products  as  needed 
for  cross  Domain  reviews 

•  Identify  gaps,  overlaps,  cross  Domain  issues 

•  Document  agreements  and  where  necessary  exercise  governance  process 

-  Develop  cross  Domain  process  for  establishing  system  migration 
investment  strategies  by  increments  (e.g.,  SV8) 

-  Establish  sustainable  infrastructure  for  support,  maintenance,  change 
control,  etc 
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Suggested  Elements  of  an  Integrated  PPBE 
Strategy  Using  PfM  and  BEA  Products 

•  Identify  what  realistically  should  be  used  by  Program  Offices, 
Components,  Domains  for  PfM  activities  in  a  variety  of  situations: 

-  Availability  of  agreed  to  “to-be”  BEA  products  (e.g.,  no  SV  at  this  time?) 

-  Consideration  for  when  and  if  legacy  “as-is”  architecture  products  are 
available,  and  the  approaches  to  be  taken  under  different  situations 

-  Definition  and  knowledge  regarding  touch  points  and  event  triggers  for 
legacy  systems  and  processes 

-  Definition  and  knowledge  of  temporal  aspects  of  touch  points  and  event 
triggers  in  order  to  resolve  UAO  and  material  weaknesses 

-  Levels  of  requirements  tracing  and  Data  Object  definitions  needed  for 
specific  assessments  (e.g.,  presently  only  for  financially  relevant  AA&V, 
personnel  visibility;  more  work  needed  for  other  Domain  areas) 

•  Too  big  an  effort  across  DoD  to  have  false  starts;  increase  confidence 
in  desired  results  by  conducting  trial/prototype  assessments 

•  Develop  an  approach  that  permits  the  consolidation  of  similar  review 
processes  -  make  the  process  as  productive  as  practical 
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Suggested  Elements  of  Data  Strategy 

•  Develop  an  integrated  Logical  Data  Model  (OV7)  with  unambiguous 
definitions  across  Domains 

•  Establish  mles  and  criteria  for  data  ownership,  use,  modification  and 
update,  persistence,  etc  in  the  context  of  where  identified  in  the  EBPM 
by  the  AIT  workshops 

•  Enter  Data  Element  definitions  in  the  XML  Data  Registry 

•  Based  on  the  “to  be”  SV-4s  and  -5s,  define  operational  requirements 
from  a  systems  perspective  to  access,  share,  distribute,  archive, 
warehouse,  or  otherwise  read,  write,  create,  and  dispose  of  data  -  from 
these  perspectives  develop  the  specific  data  storage  requirements 

•  Identify  essential  provisions  needed  to  be  compatible  with  the  yet  to  be 
implemented  GIG  Net-Centric  Data  Strategy 
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Suggested  Elements  of  Acquisition  Strategy 

•  Identify  and  establish  enterprise  capability  needs  consistent  with  the  completed 
End-to-End  process  model  (OV6c) 

-  Both  existing  capabilities  and  gaps  to  achieve  enterprise  processes 

-  Establish  and  coordinate  Domain  and  Component  priorities  and  timelines  for 
achieving  specific  capabilities 

-  Feed  results  into  the  appropriate  PPBE  and  related  PfM  processes  to  establish 
program  plans,  alternative  solutions,  acquisition  plans,  etc. 

•  Coordinate  and  establish  lead  and  support  roles  for  program  mods,  new  starts, 
etc.  that  cross  Domain,  Agency  or  Component  responsibility  boundaries 

•  As  part  of  PPBE  and  related  PfM  processes  periodically  review  acquisition 
strategies,  implementation  architectures  and  data  strategies  for  compatibility 
with  the  BEA  and  GIG  at  appropriate  levels  (Enterprise,  Domain,  Component) 

-  Domains  develop  and  coordinate  integrated  implementation  roadmaps  based  on 
Component  inputs 

-  Components  coordinate  and  develop  acquisition  and  implementation  plans  for 
system  solutions,  modifications,  or  outsourcing  alternatives  along  with  appropriate 
integration  and  testing 

•  Conduct  additional  BPR  as  appropriate,  once  a  product  is  selected 

-  Proposed  architectural  variances  require  petition  through  appropriate  governance 
processes 

•  Develop  a  transformation  roadmap  and  phased  implementation  plan 
incorporating  Domain  inputs 
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IDA  Commentary  on  Approaches  by 
Miller  (M)  and  Comes  (C) 

•  Agree  with  M  and  C  that  not  all  formal  DoDAF  products  are  necessary 

-  Agree  with  C  that  EBPM  provides  framework  adequate  for  Domain  to  work  with 
Components  to  plan  and  build  solutions 

-  At  (DoD)  enterprise  level  need  only  drill  down  to  level  adequate  to  define  cross 
Domain  touch  points 

-  Further  architecture  detail  is  a  Domain  and  Component  role 

•  Agree  with  C  on  PfM  by  Domains  requires  a  good,  well  documented 
understanding  of  processes,  shortfalls,  and  systems 

•  Agree  with  C  on  a  “confederation”  of  appropriate  functional  area  solutions, 
composed  of 

-  Vertical  elements  (“stovepipes”) 

-  Single  Domain-wide  integrated  elements 

-  Cross  Domain  elements 

-  Any  mix  of  above  (could  be  single  ERP  e.g.,  M’s  approach;  a  DoD  family  of  ERPs 
e.g.,  M’s  “fallback”  approach;  or  many  solutions  including  multiple  ERPs  e.g.,  C’s 
approach) 
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A  Problem  With  Definitions 

Many  of  the  problems  inhibiting  optimum  progress  in  BMMP  is  the  lack 
of  a  good  lexicon  of  the  several  technical  terms  that  have  different 
meanings  to  different  stakeholders,  e.g. 

-  Architecture 

•  (C)  “a  representation  of  plans,  processes,  strategies,  etc.  for 
accomplishing  an  objective” 

•  (M)  “  a  blueprint” 

•  (Compliance)  the  specific  formal  views  of  the  DoDAF 

-  Integrated 

•  (M,  Executive  DoD)  a  seamlessly  integrated  suite  of  systems,  implicitly 
with  a  uniform  data  organization 

•  (C)  accepts  a  “federated”  (or  confederation  )  set  of  (lesser  enterprise) 
systems  organized  along  both  horizontal  and  vertical  lines  (including 
“stovepipes”) 

-  Capabilities  /  Processes 

•  (C)  uses  “processes”  in  his  briefing  but  claims  that  they  are 
synonymous  with  “capabilities” 
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(C)  Summary  of  way  ahead  [IDA  Comment] 

•  Architecture 

-  Reach  consensus  on  appropriate  level  of  detail  for  “top  level”  BEA 

-  Adjust  BMSI  /  IBM  direction  and  workload  (and  workforce)  accordingly 

-  Evaluate  future  direction  and  workload  for  EBPM  effort  (after  Increment  1) 

-  Develop  clear  understanding  of  roles  and  responsibilities  for  cross-domain  integration 

•  Portfolio  Management 

-  Continue  to  develop  Domain  process  models  to  ensure  Domains  are  equipped  to  conduct 
Portfolio  Management 

-  Evaluate  success/failure  of  preliminary  Portfolio  Management  in  Program  Review 

-  Adjust  Portfolio  Management  approach  as  needed 

-  [May  not  be  able  to  achieve  uniform  PfM  approach  to  accommodate  LOG  Domain] 

•  Endorse,  then  improve  BMMP  “Solution” 

-  “Confederation”  of  “stovepiped”  solutions  for  functional  areas 

-  Align  solutions  along  Services  and  Agencies,  based  on  Domain  processes 

-  Upfront  recognition  of  need  to  link  within  and  across  Domains 

-  Commonality  of  solution  where  possible 

-  Develop,  expand  Enterprise  Integrated  Data  Environment;  “net  centric”  data  solution  in  long 
term 
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IDA  Comments  on  M’s  Solution  Approach 

•  Agree  with  M’s  “fallback  position”  on  C’s  “Summary  of  Way  Ahead” 

-  Use  ERP  family  mix  for  Component  “stovepipe” 

•  Disagree  with  M’s  comment  that  “Without  a  Common  ERP  Backbone  - 
BMMP  will  very  likely  fail” 

-  It  will  not  be  possible  to  gather  enough  coherence  within  DoD  for  such  an 
acquisition;  the  “fallback”  approach  with  multiple  ERPs  or  the 
“confederation”  approach  will  work 

•  Accept  “fallback”  position  to  allow  for  “different  ERP  implementations 
by  Components,  but  the  same  ERP  family  mix” 

-  Probably  the  “family  mix”  will  include  the  3  or  4  primary  ERP  vendors 

-  As  is  always  the  case,  there  will  be  the  occasional  need  for  outside  the 
“family  mix”  of  COTS  or  GOTS  packages  to  accomplish  some  capabilities 

•  Even  with  a  basic  ERP  solution  there  will  be  a  need  for  middleware  to 
connect  legacy  program  elements  and  databases  to  the  evolving  BMMP  - 
for  many  years  to  come 


A  Federated  Approach  to  Integration  Necessary  for  BMMP  Success 


This  briefing  was  produced  initially  for  the  “strategic  plan”  group  to  find  an  approach 
that  would  allow  for  a  number  of  ERP  solutions  that  would  work  in  a  federated  mode, 
thereby  bridging  the  differences  between  the  unitary  ERP  and  federated  approaches.  It 
had  the  effect  of  convincing  a  number  of  senior  participants  that  the  federated  approach 
was  the  one  to  be  endorsed.  In  addition  to  presentation  to  the  “strategic  plan”  group,  this 
briefing  was  presented  to  a  number  of  the  senior  line  managers,  including  the  BMMP 
director  and  the  BEA  chief  architect. 
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Important  Aspects  of  BMMP 

•  Enormously  Difficult 

-  Complex  and  dynamic  multi-facetted  “program”  spanning  all 
business  related  functions  of  the  DoD 

-  Is  “Joint”  both  horizontally  and  vertically 

-  Requires  changes  in  processes,  approaches  and  culture 

-  Executed  at  a  scale  not  here-to-for  encountered 

-  Many  thousands  of  systems  to  be  upgraded 

•  The  Stakeholder  Problem 

-  Stakeholder  community  permeates  DoD  from  top  to  bottom 

-  A  well  articulated  and  widely  disseminated  enterprise  level 
description  of  the  major  functions  encompasses  by  the  BMMP, 
the  various  stakeholders,  and  what  roles  each  is  expected  to 
take  in  the  attainment  of  the  BMMP  goals  is  lacking 


Current  Legacy  Approach 

(Problems  With  Interoperability) 
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Federation  (Confederation) 

•  Definition:  An  approach  that  allows  a  number  of  autonomous 
organizational  entities  to  participate  in  the  development  of  an 
architecture  while  retaining  a  level  of  internal  independence 

•  Interoperability  amongst  the  federated  entity  architectures  is 
achieved  with  explicit  definitions  and  oversight  established  at  the 
enterprise  level  of 

-  Standards  for  data,  processes  and  protocols 

-  Entity  roles  and  responsibilities 

-  Scope  of  actions  and  control 

•  Example:  The  GIG  is  a  federation  of  3  entities,  following  such  a  set 
of  definitions  and  using  the  common  set  of  Net-Centric  Core 
Enterprise  Services  -  the  entities  are: 

-  Warfighting  Mission  Area 

-  Business  Mission  Area 

-  National  Intelligence  Domain 


A  Data  Strategy  is  Required 

•  Coordinate  the  development  of  a  data  strategy  consistent  with  the 
GIG  Net-Centric  Data  Strategy 

•  Develop  an  integrated  Logical  Data  Model  (OV-7)  with  unambiguous 
definitions  across  Domains 

-  Enter  Data  Element  definitions  in  the  XML  Data  Registry 

•  Establish  operational  requirements  from  a  systems  perspective  to 
access,  share,  distribute,  archive,  warehouse,  or  otherwise  read, 
write,  create,  and  dispose  of  data 

•  Establish  a  data  management  approach,  including 

-  Definitions  of  data  and  meta-data  descriptions 

-  Data  transfer  protocols 

-  Defined  rules  and  criteria  for  data  ownership,  use,  modification, 
persistence,  etc. 

•  Assign  “data  ownership,”  carrying  responsibilities  for: 

•  Accuracy  •  Integrity  •  Access  control 

•  Reliability  •  Availability 


BMMP  Federated  Solution 
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BMMP  Evolution 


Current  Legacy  Solution 


BEA 

Domain  1 

Domain  2 

Domain  3 

Domain  4 

Domain  5 

Domain  6 

□ 

□ 

Sgrvicgl 

□ 

□ 

a 

a 

SrvicfP 

□ 

■ 

a 

a 

^grvicgp 

a 

B 

□ 

□ 

Sfgrvic04 

a 

1 

I  II  II  II  II  I  UZT 


Initial  Federated  Solution 


BEA 

Domain  1 

Domain  2 

Domain  3 

Domain  4 

Domain  5 

Domain  6 

i  □  Srvicill  □  □ 


E3  □  jSrvufh  □  B 

1  □  !8rvicB3  □  B 

i  □  !@rvi<fj4  0  i 

i _ ii _ n _ n _ 1 1 _ mzr 


Totally  Integrated  Solution 


Long  Term  Evolution 


► 


The  evolution  roadmap  will,  by  necessity,  follow  a  path  of  federated  solutions 
Unlikely  total  integrated  solution  will  ever  be  achieved,  and  probably  undesirable 
Approach  accommodates  changing  requirements,  environments  and  technologies 
Approach  accommodates  incremental  evolution  and  options  nearly  unlimited 
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July  2004  Comes  /  Miller  “Debate” 

Comes  Wav  Ahead  Summary  (July  12,  2004) 

•  Endorse,  then  improve  BMMP  “Solution” 

-  “Confederation"  of  “stovepiped”  solutions  for  functional  areas 

-  Align  solutions  along  Service  and  Agencies,  based  on  Domain  processes 

-  Upfront  recognition  of  need  to  link  within  and  across  Domains 

-  Commonality  of  solutions  where  possible 

-  Develop,  expand  Enterprise  Integrated  Data  Environment;  “net-centric” 
data  solution  in  long  term 

Miller’s  Solution  Approach 

•  Although  preferred  position  is  that  “Without  a  Common  ERP 
Backbone  -  BMMP  will  very  likely  fail” 

-  A  “fallback”  position  is  accepted  to  allow  for  “different  ERP 
implementations  by  Components,  but  the  same  ERM  family  mix" 

-  Probably  the  “family  mix”  will  include  the  3  or  4  primary  ERP  vendors 

-  This  can  only  work  with  federated  rules  (AB) 


A  Federated  Approach  to  Architecture  Development 


This  short  paper  is  a  revision  by  IDA  of  an  extended  definition  of  a  federated  approach 
to  architecture  development  for  the  group  responsible  for  the  Enterprise  Transition  Plan. 
Among  other  issues  the  alignment  of  the  architecture  development  along  DoD 
organizational  lines  is  explicitly  discussed. 
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A  Federated  Approach  to  Architecture  Development 


A  federated  approach  to  architecture  development  allows  a  number  of  autonomous 
organizational  components  to  participate  in  the  development  of  an  architecture  while 
retaining  a  level  of  internal  independence.  To  make  such  an  approach  work,  there  must 
be  appropriate  principles  of  federation  established  as  part  of  the  overall  governance 
process  for  architecture  development. 

There  are  two  primary  ways  that  the  autonomous  organizational  components  can 
participate  in  the  architecture  development  as  part  of  a  federated  approach  (as  opposed  to 
just  becoming  team  members  of  a  single  team  developing  the  architecture).  The  first 
involves  a  partitioning  of  the  architecture  into  parts  that  fall  under  the  control  of 
designated  organizational  units,  allowing  them  to  develop  this  part  of  the  architecture 
subject  only  to  a  set  of  framing  constraints  established  at  an  enterprise  level.  The  second 
more  loosely  organized  approach,  involves  another  independent  development  model 
based  on  that  used  in  open  source  development  projects.  Anyone  may  develop  parts  or 
aspects  of  the  architecture  and  submit  them  for  inclusion  in  the  architecture.  The  first 
approach  is  more  appropriate  to  the  purposes  and  goals  of  BMMP  and  is  discussed  in 
greater  detail  here. 

In  this  approach  autonomous  organizational  components  independently  develop 
architecture  products  that  will  produce  interoperable  component  implementations  as  part 
of  the  overall  business  system.  The  key  to  achieving  such  independent  but  coordinated 
development  is  an  appropriate  approach  to  the  standards  and  processes  of  such 
architecture  product  development,  the  appropriate  layering  and  decomposition  of  the 
overall  architecture  into  component  scopes  that  can  be  effectively  tackled  on  an 
independent  basis,  and  a  governance  and  compliance  mechanism  that  can  assess  the 
resultant  architecture  products  for  level  of  compliance  and  quality  so  as  to  assure  the 
ultimate  development  of  interoperable  components  of  the  ultimately  implemented 
business  system. 

1  The  standards  and  processes  established  for  architecture  development  (DODAF 
and  specific  guidance  on  using  DODAF,  for  instance,  as  well  as  Popkin  SA  usage 
standards)  ensure  that  appropriate  architecture  products  are  developed,  and  that  they  are 
mutually  understandable  by  all  organization  elements  involved. 

2  Appropriate  layering  and  decomposition  allows  the  overall  framing  of  an 
Enterprise  Architecture,  with  clear  identification  of  component  elements  that  need  not 
necessarily  be  visible  at  the  overall  level,  allowing  effective  independent  development  of 
the  architecture  of  such  component  areas  while  ensuring  interoperability  between  the 
various  component  parts.  The  interoperability  of  the  various  components  of  the  federation 
are  ensured  with  the  explicit  definitions  at  the  enterprise  level  of 

-  standards  for  data,  processes,  and  protocols 

-  entity  roles  and  responsibilities 
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scope  of  action  and  control 


Such  an  approach  allows  the  components  to  be  parts  of  a  monolithic  or  a  distributed  or 
federated  architecture. 

3  Interoperability  across  the  enterprise  is  ensured  by  the  various  components 
developed  according  to  the  architecture  actually  being  compliant  with  the  relevant 
standards  and  protocols.  Part  of  the  governance  effort  is  a  compliance  checking  or 
certification  capability.  Such  compliance  certification  should  be  at  two  major  levels:  one 
for  the  architecture  and  design  products  developed  by  the  autonomous  organizations,  and 
a  second  for  the  actual  component  implementations,  to  ensure  that  they  operate  as 
required  and  designed,  and  meet  minimum  performance,  security  and  safety  levels. 

The  Business  Management  Modernization  Program  (BMMP)  —  Business  Modernization 
and  Systems  Integration(BMSI)  —  manages  and  focuses  development  of  BEA  in 
accordance  with  decisions,  direction  and  oversight  provided  through  the  BMMP 
governance  structure  [Under  SecDef  Memo,  "Domain  Owners  Integration  Team  for 
BMMP"  September  15,  2003].  In  this  context,  the  following  describes  BMMP  Federated 
Architecture  controlled  roles  and  responsibilities  (Source  material:  April  2004 
CONOPS). 


Note:  The  use  of  the  term  “component”  here  may  too  easily  be  confused  with  the  DoD 
term  “Component”,  meaning  the  Services  and  Agencies.  We  may  have  to  find  another 
term. 


A.  Brenner 
10/05/2004 
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High  Level  Concept  of  Operations  for  Federated  Approach  to 

Architecture 


This  briefing  was  prepared  for  Paul  Brinkley  USD(AT&L)  and  Tom  Modley  USD(C), 
the  recently  appointed  OSD  level  individuals  jointly  responsible  for  DoD  Business 
Mission  Area  transformation.  At  the  request  of  the  director  BMMP,  IDA  had  started 
developing  a  Federated  Architecture  CONOPS  at  the  end  of  2004.  This  briefing  was 
designed  to  share  the  thinking  on  the  matter  with  the  senior  participants. 
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HIGH  LEVEL  CONCEPT  OF  OPERATIONS 
FOR  FEDERATED  APPROACH  TO 

ARCHITECTURE 


February  22,  2005 


PREFACE,  OBJECTIVE  and  VISION 


•  PREFACE 

-  NDAA  requirements 

•  OBJECTIVE 

-  Business  transformation  to  better  support  the  Warfighter  and  modernize 
its  business  management  processes 

-  Requirements  for  a  business  enterprise  architecture  (BEA)  and  a 
business  transition  plan  (BTP) 

•  VISION 

-  Recognition  of  DoD  organization,  history,  culture  and  Public  Law  leads 
to  a  need  for  a  federated  approach  to  accomplish  business 
transformation 

-  Federated  approach  makes  possible  the  development  of  a  BEA  and 
BTP 


DEFINITIONS 


•  ENTERPRISE  ARCHITECTURE 

-  NDAA  definition 

•  FEDERATION 

-  BMA  is  a  member  of  the  GIG  (a  federation) 

-  BMA  federation  members  include 

•  OSD  entities  Business  domains 

•  Joint  Staff  Combatant  Commands 

•  Military  Services  and  Agencies 

•  FEDERATED  ARCHITECTURE 

-  “An  approach  for  enterprise  architecture  development  that  is  composed  of  a  set  of 
coherent  but  distinct  entity  architectures  —  the  architectures  of  the  separate  members 
of  the  federation.” 

•  HIERARCHICAL  ENTERPRISE  ARCHITECTURES  AND  TRANSITION  PLANS 

-  BEA-BMA  (BTP-BMA)  is  the  guiding  framework;  NDAA  September  2005  delivery 

-  BEA-xxx  (BTP-xxx)  is  the  EA  (TP)  for  federation  member  xxx 

-  BEA  (BTP)  is  composite  EA  (TP)  encompassing  all  levels  of  the  federation 


BACKGROUND,  PURPOSE  AND  SCOPE 

•  BACKGROUND 

-  Current  status  of  BMA  information  systems 

•  OMB,  Congressional  and  GAO  positions 

-  Argument  for  federated  approach  for  transformation 

-  NDAA  mandated  governance  structure  summary 

•  Additional  organizational  structure 

-  NDAA  mandated  deliverables 

•  BEA-BMA  and  BTP-BMA 

•  PURPOSE 

-  High  level  CONOPS  for  federated  approach 

•  SCOPE 

-  Covers  all  DoD  business  systems  and  the  capabilities  and  processes 
supported  by  these  systems 


KEY  FEDERATED  ARCHITECTURE  OPERATIONAL 

PRINCIPLES 

•  BMA  business  system  implementations  support  interoperability  and  integration  by 
sharing  data  and  BMA-Services  across  the  federation  and  other  GIG  mission  areas 

•  BEA  and  BTP  are  aggregations  of  EAs  and  TPs  of  all  federation  members 

-  Documents  business  and  financial  rules  and  policies,  activities,  functional  processes,  roles 
and  data  objects  and  strategies;  defines  migration  path 

-  Provides  integrated  view  of  BMA,  facilitating  BPR  and  portfolio  management 

•  BEA-BMA  and  BTP-BMA  document  the  common  rules  to  guide  architecture  and  TP 
development  by  all  federation  members 

•  COIs  to  be  established  to  address  organization,  data  and  BMA-Services  issues 

•  As  Business  Transformation  proceeds 

-  Redundant  less  effective  legacy  systems  will  be  retired 

-  Opportunities  for  reuse  of  generic  products  will  grow 

•  Multiple  levels  of  organizational  hierarchy  are  to  be  accommodated  including 

-  From  DoD  enterprise  to  Dod  Programs 

-  DoD  commercial  partners  and  other  USG  agencies 


KEY  RESPONSIBILITIES  FOR  FEDERATED 
ARCHITECTURE  OPERATIONS 

•  DBSMC,  working  through  AAs  and  working  groups,  with  support  of 
Components/Agencies  and  OBT  (BTRA) 

-  Develop  BEA-BMA  and  BTP-BMA 

-  Establish  rules  of  federation,  and  BEA  and  BTP  consolidation 

-  Define  time-phased  milestones  and  performance  metrics 

-  Identify  financial  and  non-financial  resource  needs 

-  Develop  a  process  for  establishing  COIs 

•  AAs  working  with  their  IRBs  have  full  responsibility  for  defense  business  systems 
under  their  jurisdiction 

•  IRBs  review  all  defense  business  systems  under  their  jurisdiction 

-  At  least  annual  review  of  all  defense  business  systems 

-  Ensure  consistency  with  DBSMC  guidance 

-  Approval  as  an  investment  before  funds  obligation 

•  Components/Agencies  and  CBM  leaders 

-  Develop  their  mission  oriented  architectures  and  transition  plans 

-  Ensure  the  architectures  and  transition  plans  result  in  proper  implementations 

•  OBT  (BTFtA)  supports  all  elements  of  the  BMMP 

-  Assess  submissions  for  compliance  with  federation,  technical  and  policy  issues 

-  Develop,  consolidate  and  maintain  the  BEA  and  BTP 

-  Evaluate  architectural  variances  and  cross-mission  conflicts 

-  Maintain  the  several  registries 
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High  Level  Concept  of  Operations  for  Department  of  Defense  Business 
Management  Modernization  Program  Federated  Approach  to 
Architecture  and  Transition  Plan,  Development,  and  Maintenance 


This  paper  was  developed  by  IDA  at  the  request  of  the  director  BMMP,  starting  at  the 
end  of  2004  over  a  four  month  period.  Partly  because  of  the  changing  organizational 
structure  of  the  BMMP  that  was  ongoing  simultaneously,  this  paper  necessarily 
underwent  a  number  of  revisions  so  as  to  keep  it  aligned  with  the  evolving  organization. 
The  organizational  changes  were  made  in  response  to  directives  by  Congress  in  the 
National  Defense  Authorization  Act  of  2005. 

On  April  20,  2005  version  13  of  the  CONOPS  was  delivered  to  the  BEA  chief  architect 
for  further  refinement  and  distribution.  The  then  chief  architect  retired  shortly  afterwards 
and  her  replacement  did  complete  refining  the  CONOPS  by  July  1.  Since  that  time,  yet 
another  individual  has  been  appointed  chief  architect,  and  the  refined  version  of  the 
CONOPS  has  yet  to  be  coordinated  and  distributed. 
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Draft  CONOPS,  V.13,  4/20/2005 


Annex  B 


HIGH  LEVEL  CONCEPT  OF  OPERATIONS 

FOR 

DEPARTMENT  OF  DEFENSE 

BUSINESS  MANAGEMENT  MODERNIZATION  PROGRAM 
FEDERATED  APPROACH  TO  ARCHITECTURE  AND  TRANSITION  PLAN, 
DEVELOPMENT  AND  MAINTENANCE 


PREFACE:  The  Business  Management  Modernization  Program  (BMMP)  was  established  in 
2001  for  the  purpose  of  modernizing  the  Department  of  Defense’s  (DoD’s)  business  information 
systems  in  order  to  meet  business  management  goals.  The  BMMP  was  implemented  by  the 
Business  Modernization  and  Systems  Integration  (BMSI)  office  which  focused  on  the 
development  of  a  comprehensive  information  systems  architecture — the  Business  Enterprise 
Architecture — for  DoD’s  Business  Mission  Area  (BMA).  That  effort  was  only  partially 
successful.  The  National  Defense  Authorization  Act  (NDAA)  for  FY2005  is  the  congressional 
mandate  to  DoD  to  continue  with  the  BMMP  but  under  closer  DoD  oversight.  It  requires  DoD  to 
develop  a  business  enterprise  architecture  and  an  attendant  business  transition  plan  for  the 
business  management  information  systems  specified  by  that  enterprise  architecture  by  September 
2005. 

1 .  OBJECTIVE:  The  Secretary  of  Defense  has  committed  to  improve  the  performance  of  the 
DoD  Business  Mission  Area  to  more  effectively  support  the  Warfighter  and  to  modernize  its 
business  management  processes.  A  Business  Enterprise  Architecture  (BEA)  and  a  Business 
Transition  Plan  (BTP)  are  required  to  drive  the  necessary  business  transformation  to 
accomplish  these  goals.  Together  these  will  provide  an  architecture  and  a  roadmap  leading  to 
an  attainable  business  solution  interoperability,  which  satisfies  the  mission  needs  across  DoD 
for  the  transformation  to  optimize  support  for  the  Warfighter. 


2.  VISION:  DoD  will  effectively  support  the  Department’s  transformation  efforts  in  support  of 
the  Warfighter  by  taking  a  federated  approach  to  develop  and  maintain  an  architecture  and  a 
transition  plan  to  guide  modernization  of  the  BMA.  Taking  cognizance  of  the  realities  of 
how  DoD  is  currently  organized,  a  consequence  of  history,  culture,  and  changing  Public  Law, 
this  federated  approach  is  an  effective  way  to  bring  about  the  desired  business  transformation. 
It  allows  for  a  number  of  heterogeneous  organizations,  both  peer  and  hierarchical,  to  develop 
and  maintain  a  BEA  and  an  associated  BTP,  providing  an  integrated  view  of  the  DoD  BMA 
modernization  effort  that  permits  organizations  and  entities  to  retain  a  dedicated  focus  on 
mission  specific  solutions  and  achieve  overall  BMA  transformation  goals  and  objectives. 
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3.  PURPOSE:  This  document  provides  a  high-level  concept  of  operations  (CONOPS)  view  for 
a  federated  approach  for  the  development  and  maintenance  of  the  BEA  and  the  BTP, 
including  considerations  for  mission  and  technology  change  and  evolution.  It  also  identifies 
the  organizational  responsibilities  and  the  associated  accountabilities. 

4.  SCOPE:  The  BEA  and  the  BTP  encompass  all  BMA  architecture  initiatives  and 
implementation  transition  planning  at  all  functional  levels,  and  covers  all  DoD  business 
systems  and  the  functions  and  activities  supported  by  such  systems.  The  BTP  includes  all  the 
corresponding  solutions  for  implementing  the  BEA. 

5.  DEFINITIONS:  Many  information  technology  (IT)  related  terms  are  used  without  clear 
definitions  as  to  their  meaning,  opening  opportunities  for  misinterpretation  of  the  intended 
meaning.  To  minimize  misinterpretation,  some  of  the  more  problematic  terms  are  defined 
here.  Other  IT  terms  are  defined  in  the  attached  Glossary. 

Enterprise  Architecture  (NDAA  definition4 5) 

“(A)  means— 

(i)  a  strategic  information  asset  base,  which  defines  the  mission; 

(ii)  the  information  necessary  to  perform  the  mission; 

(iii)  the  technologies  necessary  to  perform  the  mission;  and 

(iv)  the  transitional  processes  for  implementing  new  technologies  in  response 
to  changing  mission  needs;  and 

(B)  includes— 

(i)  a  baseline  architecture; 

(ii)  a  target  architecture;  and 

(iii)  a  sequencing  plan.” 

Federation  1  -  An  organizational  entity  composed  of  smaller  organizational  divisions 
united  to  achieve  a  common  goal,  within  which  the  smaller  divisions  retain  for 
themselves  control  over  local  matters. 

The  BMA  is  a  member  of  the  larger  DoD  Global  Information  Grid  (GIG)  federation.  The 
GIG  federation  also  includes  the  Warfighter,  Intelligence  Community,  and  Enterprise 
Information  Environment  Mission  Areas.  Within  the  BMA,  the  enterprise  federation 
members  include  the  four  BMA  Approval  Authority  entities  (see  Section  6.d.  below),  and 
the  Military  Services  and  Agencies.  Within  each  of  these  organizations  there  likely  will 
be  additional  levels  of  federation. 

Federated  Architecture  -  An  approach  for  enterprise  architecture  development  that  is 
composed  of  a  set  of  coherent  but  distinct  entity  architectures;  the  architectures  of  the 
separate  members  of  the  federation. 

With  this  approach  the  members  of  the  federation  participate  to  produce  an  interoperable, 
effectively  integrated  enterprise  architecture.  The  federation  sets  the  overarching  rules  of 
the  federated  architecture,  defining  the  policies,  practices  and  legislation  to  be  followed, 


4  “The  term  ‘enterprise  architecture’  has  the  meaning  given  that  term  in  section  3601(4)  of  title  44,  United 
States  Code.” 

5  The  definition  is  a  composite  from  two  respected  dictionaries:  Webster’s  Third  New  International 
Dictionary,  Unabridged  (Merriam  Webster,  1986);  and  Encarta®  World  English  Dictionary  (Bloomsbury 
Publishing,  2004). 
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as  well  as  the  inter-federate  procedures  and  processes,  data  interchange,  and  interface 
standards,  to  be  observed  by  all  members  of  the  federation.  Each  federation  member 
conforms  to  the  enterprise  view  and  overarching  rules  of  the  federation,  in  developing  its 
architecture.  Internal  to  themselves,  each  focuses  on  their  separate  mission  and  the 
architecture  that  best  supports  that  mission. 


Hierarchical  Architectures  and  Transition  Plans6 

Within  the  BMA  federation  there  is  a  single  DoD-wide  business  enterprise  architecture 
and  a  number  (~35)  of  Component7  business  enterprise  architectures,  reflecting 
Component  -specific  capabilities.  There  is  also  a  guiding  framework  accommodating  the 
common  capabilities,  data  standards,  rules,  and  the  operating  requirements  that  are  DoD- 
wide.  Figure  1  illustrates  the  BMA  enterprise  level  of  architecture.  Federated  elements 
within  any  of  these  enterprise  federation  members,  obey  the  rules  of  their  federation 
parents  and  are  not  designated  as  “enterprise.” 
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Figure  1.  Defense  Federated  Business  Enterprise  Environment 


To  distinguish  the  various  levels  of  the  federated  approach  to  develop  the  BMA 
enterprise  architecture  and  transition  plan,  the  following  designations  are  assigned: 

•  BEA-BMA  represents  the  guiding  framework  for  all  BMA  business  enterprise 
architecture.  It  is  sufficiently  defined  to  effectively  guide,  constrain,  and  permit 
implementation  of  interoperable  defense  business  systems  solutions.  It  is  the 
topmost  level  of  BEA-DoD. 


6  Here  and  elsewhere  in  this  CONOPS,  the  term  “transition  plan”  at  the  enterprise  level  is  to  be  understood 
to  be  the  “Enterprise  Transition  Plan  and  Program  Baseline.” 

7  Here  and  elsewhere  in  this  CONOPS,  Components  (capital  C)  means  the  Military  Departments/Services 
(Army,  Air  Force,  Navy,  Marine  Corps)  and  the  Defense  Agencies. 
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o  Corresponds  to  the  NDAA  definition  for  September  2005  delivery8 

•  BTP-BMA  represents  the  guiding  framework  for  all  BMA  business  enterprise 
transition  planning  and  the  implementation  strategy  for  new  and  modified 
systems.  It  addresses  the  acquisition  strategy  for  systems  that  are  expected  to  be 
needed  to  complete  the  defense  business  systems  transformation. 

o  Corresponds  to  the  NDAA  definition  for  September  2005  delivery9 

•  BEA-DoD  is  the  enterprise  architecture  of  the  DoD-wide  federation.  It  includes 
the  BEA-BMA  and  integrates  enterprise  architecture  information  for  all  the  Core 
Business  Mission  Areas  (CBMA),  their  reporting  extensions,  and  the  BMA 
oriented  services  extensions,  designated  as  Business  Enterprise  Services  (BES), 
not  included  in  the  Net-Centric  Enterprise  Services  (NCES)  provided  by  the 
ASD(Networks  and  Information  Integration)/DoD  CIO10. 

•  BTP-DoD-xxx  is  the  transition  plan  for  DoD  OSD  entity  xxx,  which  owns  and 
manages  business  information  systems  that  support  work  for  which  the  entity  is 
responsible.  This  includes  each  Core  Business  Mission  and  other  OSD  entities  as 
appropriate. 

•  BEA-yyy  is  the  enterprise  architecture  of  Component  federation  member  yyy. 

•  BTP-yyy  is  the  transition  plan  of  Component  federation  member  yyy. 

•  BEA  represents  the  composite  BMA  enterprise  architecture  encompassing  all 
federation  members. 

•  BTP  represents  the  composite  BMA  transition  plan  encompassing  all  federation 
members. 


6.  BACKGROUND: 

a.  The  current  status  of  the  information  systems  supporting  the  Department’s  BMA  has 
been  called  into  question  on  numerous  occasions  by  Congress,  the  Office  of 
Management  and  Budget  (OMB),  and  the  Government  Accountability  Office  (GAO). 
The  current  information  technology  systems  supporting  the  BMA  have  been  growing 
and  expanding  for  decades  without  an  overall  Department-wide  plan  or  enterprise- 
level  guidance.  The  Secretary  of  Defense  (SECDEF)  made  it  one  of  his  priorities  to 
rectify  these  deficiencies  and  the  development  of  the  BEA,  along  with  the 
corresponding  BTP,  is  a  major  step  in  that  effort. 

b.  The  BEA-BMA  provides  the  Department  with  the  end-to-end  architectural 
perspective  of  BMA  functions  and  processes.  It  includes  the  necessary  information 
infrastructure  to  ensure  interoperability  within  the  BMA  and  across  the  Warfighter 
and  Intelligence  Mission  Areas  and  is  supported  by  the  underlying  Enterprise 
Information  Environment  (EIE)  Mission  Area. 


8  Additionally  the  delivery  to  Congress  will  include  an  initial  set  of  Component  and  DoD-wide  architecture 
products  associated  with  current  BMA  transformation  activity. 

9  Additionally  the  delivery  to  Congress  will  include  an  initial  set  of  transition  plans  delineating  current 
BMA  transformation  activity. 

10  Hereafter  designated  as  NII/CIO  here. 
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c.  A  federated  approach"  to  architecture  development  most  easily  accommodates  the 
diverse  functions  and  missions  of  the  Department  and  allows  an  orderly  and  phased 
execution  and  modernization  of  the  thousands  of  systems  that  currently  support  the 
Departments’  diverse  functions  and  missions.  This  approach  provides  a  coordinated 
hierarchy  of  enterprise  architecture  elements  capable  of  supporting  the 
implementation  of  solutions  and  the  associated  transition  planning  to  achieve  the 
envisioned  modernization  goals  and  objectives. 

d.  The  NDAA  provides  for  a  governance  structure  vested  in  the  Defense  Business 
Systems  Management  Committee  (DBSMC)  to  exercise  oversight  and  approval  of 
defense  business  systems  modernization  activities.  Accountability  for  the  various 
defense  business  systems  is  assigned  to  four  principal  members  of  the  DBSMC  (i.e., 
USD(AT&L),  USD(C),  USD(P&R),  and  ASD(NII))  -  the  Approval  Authorities 
(AAs).  Each  AA  is  required  to  establish  an  Investment  Review  Board  (IRB)  with 
responsibility  to  review  defense  business  systems  under  its  jurisdiction,  with  a  total 
cost  in  excess  of  $1M,  as  a  sound  investment  consistent  with  the  guidance  from  the 
Secretary  of  Defense  and  the  DBSMC.  Additional  organizational  structure  is 
proposed  to  support  these  including: 

i.  Office  of  Business  Transformation  (OBT)  which  includes: 

•  Transformation  Support  Office  (TSO)  -  the  evolution  of  the  BMSI  office  - 
to  support  all  aspects  of  the  DoD  business  transformation  effort 

•  BMMP-PEO  for  DoD  Enterprise  Programs  with  responsibility  for 
development  of  systems  assigned  to  the  DoD-wide  federation; 

ii.  Five  Core  Business  Missions  (CBMs)  are  also  defined,  represented  by  a  PSA 
Under  Secretary  and  in  some  cases  jointly  with  a  flag-rank  Warfighter,  linking  the 
BMA  and  the  Warfighting  Mission  Area  (WMA),  and  driving  the  DoD  business 
transformation. 

e.  The  Secretary  of  Defense,  acting  through  the  DBSMC,  is  required  by  the  NDAA  to 
develop: 

i.  “An  enterprise  architecture  to  cover  all  defense  business  systems,  which  shall  be 
sufficiently  defined  to  effectively  guide,  constrain  and  permit  implementation  of 
interoperable  defense  business  system  solutions  consistent  with  the  policies  and 
procedures  established  by  the  Director  of  the  OMB;  ” 

ii.  “A  transition  plan  for  implementing  the  enterprise  architecture  for  defense  business 
systems.” 


7.  KEY  FEDERATED  ARCHITECTURE  OPERATIONAL  PRINCIPLES: 

a.  The  DoD  BEA  is  an  information  infrastructure  and  a  DoD  strategic  asset  that  defines 
the  business  processes  of  the  Department  to  support  its  business  missions.  It  is  an 


11  Various  governance  styles  and  mechanisms  can  be  used  to  manage  and  oversee  business  programs 
depending  on  the  main  business  orientation  of  an  organization.  In  the  DoD,  there  is  a  need  for  an  enterprise 
approach  to  business  processes  that  cuts  across  organizational  entities  including  OSD,  JCS,  the  Military 
Services  and  Agencies,  and  for  synergistic  information  systems  to  support  them.  Since  existing  DoD 
governance  includes  decision  making  processes  largely  done  through  executive  committees,  a  federated 
approach  to  governance  has  been  found  both  in  government  as  well  as  private  industry  to  best  meet  this 
need  and  condition. 
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enterprise  architecture  as  defined  in  the  NDAA,  and  it  will  be  consistent  with  the 
Federal  Enterprise  Architecture,  as  represented  by  the  DoD  Reference  Models. 

b.  BMA  business  systems  solution  implementations,  conforming  to  the  BEA,  will 
experience  interoperability  and  effective  integration  by  adhering  to  the  rules  of  the 
federation,  which  supports  sharing  of  data  and  BMA  oriented  enterprise  services,  the 
BES,  across  the  GIG  mission  areas  and  the  various  BMA  federation  members,  by 
ensuring  compliance  with  the  following: 

i.  A  federated  data  strategy,  which  is  an  integral  part  of  and  compliant  with  the  Net- 
Centric  Enterprise  strategy,  as  required  by  the  NII/CIO,  establishing  guidelines  for 
data  and  meta-data  definition,  data  publishing,  and  subscription  aided  by  discovery, 
mediation,  and  messaging; 

ii.  Using  GIG  NCES  that  enables  data  tagging,  sharing,  searching,  retrieving  and 
information  assurance;  and 

iii.  Data  sharing  that  should  be  done  in  ways  that  preserve  the  meaning  and 
relationships  inherent  in  that  data,  without  concern  for  technical  details  of  how  the 
data  is  created,  stored  locally,  or  used  in  any  of  the  defense  business  systems.  It 
should  conform  to  the  federation  rules  for  data  accuracy,  reliability,  and  timeliness 
and  for  data  ownership,  stewardship,  use  modification,  persistence,  access, 
security,  and  interchange,  and  make  all  data  accessible  to  authorized  Department 
users  and  other  Government  and  non-Govemment  communities,  including  both 
anticipated  and  unanticipated  users  and  applications; 

iv.  BES  support  interoperability  in  compliance  with  the  Net-Centric  Operations 
Warfare  (NCOW)  Reference  Model  (NCOW-RM)  and  the  Net-Ready  Key 
Performance  Parameters,  as  defined  by  the  Chairman  Joint  Chiefs  of  Staff  (CJCS) 
Instructions;  and 

v.  A  governance  process  established  by  the  DBSMC  for  the  federated  approach  to 
architecture  development,  maintenance,  update,  consolidation,  usage,  and  the 
necessary  procedures  for  the  effective  performance  and  activities  of  the  federation. 
The  DBSMC  governance  will  also  ensure  that  these  procedures  are  reviewed, 
modified,  followed,  and  evaluated  for  compliance. 

c.  The  BEA  and  the  BTP  are  an  integration  of  the  architectures  and  transition  plans  of 
all  of  the  federation  members.  Moreover,  the  architectures  and  transition  plans  of 
each  of  the  enterprise  federation  members,  (e.g.,  the  AAs,  DoD-wide  and 
Components),  will  also  represent  an  amalgamation  of  those  of  supporting  federation 
members,  representative  of  the  diverse  spheres  of  business  activity  for  which  they 
have  responsibility.  Note,  that  both  of  these  are  evolutionary  products  that  will 
change  with  time  to  accommodate  to  the  continuously  changing  mission 
requirements,  technology  advancements  and  ongoing  process  improvements. 

d.  The  development  of  the  BEA  at  all  levels  of  the  federation  is  guided  by  the  BEA- 
BMA,  and: 

i.  Facilitates  effective  business  process  reengineering  (BPR); 

ii.  Must  accommodate  bottom-up  initiatives  to  find,  define  and  resolve  what  may  be 
initially  evident  as  a  local  issue;  and 
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iii.  Architectural  artifacts  should  only  be  developed  to  the  extent  necessary  and  as 
needed,  avoiding  architecture  development  just  to  develop  architecture  -  called 
“just-in-time  architecture.” 

e.  The  BTP  defines  how  the  Department  will  migrate  from  its  current  “As  Is”  inventory 
of  business  systems  and  operations  to  achieve  the  modernized  “To  Be”  state 
documented  in  the  BEA,  which: 

i.  For  the  September  2005  delivery  to  Congress  includes: 

•  Listing  of  business  “legacy  systems”  (as  of  December  2002)  that  will  not  be 
part  of  the  objective  BEA,  together  with  the  schedule  for  terminating  those 
systems  that  provides  for  reducing  the  use  of  those  legacy  systems  in  phases 

•  Listing  of  those  legacy  systems  that  will  be  a  part  of  the  objective  BEA, 
together  with  a  strategy  for  making  the  modifications  to  those  systems  that 
will  be  needed  to  ensure  that  such  systems  comply  with  the  BEA-BMA. 

f.  The  BEA  along  with  the  BTP  enables  informed  decision-making  and  sound 
investment  planning  essential  for  effective  DoD  Portfolio  Management  (PfM). 
Additionally,  they  enable  the  traceability  needed  to  determine  the  impact  of  changes 
to  compliance  rules,  requirements,  and  process  changes  within  and  between  business 
areas,  thereby  facilitating  evolution  of  the  BMA  transformation. 

g.  The  BEA-BMA  documents  the  uniform  and  common  DoD  business  enterprise 
reference  rules,  requirements  and  information  infrastructure  to  guide  the  development 
of  architectures  by  all  members  of  the  federation.  This  enables  the  federated  approach 
to  work  by  supporting  architecture  development  by  the  diverse  executing  entity 
implementations  to  achieve  the  goals  for  business  transformation,  including: 

i.  Allowing  for  and  accommodating  the  existence  of  a  number  of  interacting 
homogeneous  and  heterogeneous  organizations  that  operate  at  the  same  or  different 
levels  of  either  functional  or  organizational  responsibility; 

ii.  Providing  the  executing  entities  within  the  governance  structure  with  the  necessary 
flexibility  to  instantiate  the  BEA  in  a  manner  that  allows  for  mission  specificity  and 
the  achievement  of  the  required  capabilities; 

iii.  Providing  the  procedures  and  rules  for  federating  and  consolidating  the  architecture 
and  transition  plans  of  lower  levels  up  to  the  higher  levels; 

iv.  Providing  guidelines  for  the  escalation  of  federated  architecture,  data  strategy, 

BES,  and  transition  planning  issues  through  the  defined  governance  process; 

v.  Providing  an  ontology  and  strategy  such  that  the  BEA  will  support  the  goals  for 
interoperability  and  integration  set  forth  by  the  NDAA,  the  NIECIO  guidelines  and 
directives,  and  CJCS  Instructions; 

vi.  Providing  a  Configuration  Management  (CM)  process  and  Configuration  Control 
Board  (CCB)  that  allows  for  and  encourages  an  orderly  mission  and  technological 
evolution  of  the  BEA  and  maintains  an  orderly  and  consistent  identification  of 
solution  configurations,  including  architecture  artifacts,  software  configuration 
items,  hardware  configuration  items,  and  documentation  throughout  the  life-cycle; 

vii.  Providing  the  necessary  framework  for  the  Core  Business  Mission  leaders,  AAs, 
and  Components  to  establish  their  “To  Be”  vision,  and  to  enable  their  functional 
process  transformation,  business  system  modernization,  associated  data  and 
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services  strategy,  and  support  of  their  Portfolio  Management,  while  ensuring  the 
aforementioned  DoD-wide  goals  in  support  of  the  integrated  end-to-end  missions 
of  the  Warfighting  and  Intelligence  Community  Mission  Areas; 

viii.  Establishing  a  number  of  common  BMA  catalog  and  registry  repositories12, 

consisting  of  organized  databases,  containing  the  formal  descriptors  of  all  aspects 
of  the  BEA.  Most  of  these  will  be  logically  enterprise-wide  databases,  although 
physically  they  may  be  distributed.  These  repositories  will  include  among  others: 

•  Rules  of  the  federation,  including  system  interface  standards,  processes,  and 
procedures,  both  internal  and  external  to  DoD 

•  Appropriate  DoD  and  federal  policies  and  regulations 

•  DoDAF  architectural  products 

•  BMA  reference  models 

•  Architectural  artifacts  and  transition  plans  at  all  levels  of  the  federation 

•  Data  and  meta-data  as  defined  by  NIECIO  and  BMA  Net-Centric  strategy 

•  BMA  data  authoritative  sources 

•  BES,  including  the  provider  of  those  services 

•  Solution  implementations  as  product  or  system  candidates  for  reuse. 

h.  The  BTP-BMA  documents  the  requirements  to  guide  the  development  of  transition 
plans  by  all  members  of  the  federation. 

i.  While  focusing  on  the  Business  Mission  Area,  the  federated  approach  must 
accommodate  and  be  inclusive  of  the  functional  data  requirements,  solutions,  and 
services  (e.g.,  what  is  needed)  by  other  GIG  mission  areas. 

j .  A  successful  federated  development  and  maintenance  initiative  requires  a  prudent 
layering  and  decomposition  of  the  overall  architecture  into  the  appropriate  levels 
(scope).  The  federated  architecture  initiative  will  be  coordinated  at  the  BEA-BMA 
level  through  the  common  application  of  procedures  and  standards  throughout  the 
federation,  to  enable  the  consolidation  of  architecture  elements  in  order  to  achieve  the 
established  objectives  and  goals  for  the  BEA.  The  interoperability  of  the  solutions  or 
systems  as  implemented  by  the  various  members  of  the  federation,  is  ensured  with 
explicit  definitions  at  the  enterprise  level  of,  or  included  in: 

•  GIG  policies,  including  NCOW-RM,  Net  Ready  Key  Performance 
Parameters,  NIECIO  Net-Centric  Enterprise  strategy,  and  BMA  Net-Centric 
Enterprise  strategy 

•  Architecture  component  terms  and  definitions 

•  Standards  for  data,  processes,  and  protocols 

•  Entity  roles  and  responsibilities 

•  Scope  of  action  and  control 

•  Defined  capabilities  and  supporting  system  functions 


12  For  a  more  detailed  list  of  and  responsibilities  for  these  repositories,  see  a  briefing  entitled  “Managing  & 
Developing  Enterprise  Architecture  in  a  Federated  Environment.” 
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•  Relationships  between  systems,  defined  functions,  supported  capabilities, 
and  the  BEA. 

k.  Communities  of  Interest  (COIs)13  will  be  established  to  address  organization, 
management,  data,  and  BES  issues  of  specific  interest  to  that  particular  community 
with  the  following  characteristics: 

i.  COIs  are  formed  to  solve  a  mission  need  and  are  comprised  of  all  identified 
stakeholders.  They  may  be  aligned  along  a  single  functional  need  or  may  be  cross 
functional.  They  are  recognized  entities,  comprising  both  formally-sanctioned  and 
ad  hoc  types  that  impact  programs  and  organizations.  Initially,  the  sanctioned  COIs 
might  include  those  aligned  with  each  of  the  five  Core  Business  Missions,  the  high 
priority  CBM  capabilities  approved  for  near  term  implementation,  and  one  COI 
representing  collectively  the  IRBs; 

ii.  It  is  important  that  the  COIs  are  established  with  strong  leadership  and  where 
appropriate  should  be  tightly-connected  to  the  appropriate  AAs. 

l.  As  the  Business  Transformation  of  the  Department  proceeds: 

i.  Redundant  and  less  effective  legacy  systems  will  be  retired; 

ii.  The  new  replacement  defense  business  systems  solutions  implemented  in 
compliance  with  the  BEA  will  provide  opportunities  for  reuse  of  certain  common 
or  generic  implemented  products.  Potentially  reusable  components  of  products  or 
solution  products,  characterized  in  terms  of  capabilities,  are  designated  as 
“templates.”  14  These  templates  will  become  available  for  use  by  other  members  of 
the  federation,  and  are  registered  in  the  BMA  template  registry.  The  availability  of 
these  templates  will  facilitate  reuse  of  relevant  architectural  components  or  of 
solution  products,  and  provide  faster  and  less  costly  implementation  of  business 
systems  solutions  across  the  Department; 

iii.  All  new  solution  initiatives  will  be  required  to  search  the  BMA  template  registry 
for  entries  that  may  be  appropriate  solutions  for  the  new  initiative.  These  should  be 
considered  when  preparing  an  Analysis  of  Alternatives  (AoA)  in  support  of  the 
proposed  solution. 

m.  The  BEA  federated  architectural  elements  and  transition  plan  will  be  developed, 
maintained,  updated,  consolidated,  and  implemented  at  all  levels  of  the  DBSMC- 
approved  federation  organizational  hierarchy.  It  must  accommodate  the  following 
levels  of  organizational  hierarchy: 

•  Business  Mission  Area 

•  Core  Business  Missions 

•  DoD-wide  business  Programs/Systems  solutions  (BMMP-PEO) 

•  Components 

•  Programs/Systems  solutions 


13  For  policy  statement  regarding  COIs,  see  “DoD  Directive  8320.2,  Data  Sharing  in  a  Net-Centric 
Department  of  Defense”  (December  2,  2004). 

14  A  “template”  as  used  in  this  context  means  a  description  (architectural,  capability,  functional,  etc.)  of  a 
working  program,  system  or  process  that  may  have  utility  in  areas  outside  that  of  the  entity  responsible  for 
its  instantiation. 
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•  DoD  commercial  partners 

•  Other  US  Government  Agencies. 


8.  KEY  RESPONSIBILITIES  FOR  FEDERATED  ARCHITECTURE  OPERATIONS15: 

a.  The  DBSMC,  working  through  the  AAs  and  the  governance-established  working 
groups,  with  the  support  of  the  Components  and  the  OBT  is  responsible  for: 

i.  Developing  the  BEA-BMA,  that,  at  a  minimum,  will  enable  DoD  to 

•  More  effectively  support  the  Warfighter 

•  Comply  with  all  Federal  accounting,  financial  management,  and  reporting 
requirements 

•  Integrate  budget,  accounting,  and  program  information  and  systems 

•  Provide  for  the  systematic  measurement  of  performance,  including  the  ability 
to  produce  timely,  relevant  and  reliable  financial  information; 

ii.  Developing  policies,  procedures,  data  standards,  and  system  interface  requirements 
that  are  to  apply  uniformly  throughout  DoD  by  defining  the  rules  of  federation  (see 
Section  7.b.),  and  documented  in  the  BEA-BMA  (see  Section  7.g.); 

iii.  Developing  the  BTP-BMA,  including  specific  time-phased  milestones, 
performance  metrics,  identification  of  the  financial  and  non-financial  resource 
needs,  and  an  acquisition  strategy  for  new  systems  that  are  expected  to  be  needed 
to  complete  the  BMA  transformation; 

iv.  Serving  as  the  final  arbiter  to  resolve  or  adjudicate  any  BMA  federation  issue  as  it 
relates  to  the  BE  A  or  BTP. 

b.  The  AAs  are  responsible  for  the  review,  approval,  and  oversight  of  the  planning, 
design,  acquisition,  deployment,  operation,  maintenance,  and  modernization  of 
defense  business  systems  under  their  jurisdiction  through  responsibility  for: 

•  Business  Enterprise  Architecture 

•  Portfolio  Management 

•  Transition  Planning. 

c.  The  IRBs,  established  by  each  of  the  AAs,  have  the  responsibility  to  review  all 
defense  business  systems  for  which  the  AA  is  responsible,  with  a  projection  of  cost 
benefits  and  risks,  including: 

i.  Review  and  approval  as  an  investment  before  the  obligation  of  funds  on  the 
system;, 

ii.  Periodic  review,  not  less  than  annually,  of  every  defense  business  system 
investment; 

iii.  Representation  on  each  IRB  by  appropriate  officials  from  among  the  Military 
Services,  Combatant  Commands,  the  Joint  Chiefs  of  Staff,  and  Defense  Agencies; 


15  Note  that  this  paper  is  an  Annex  to  a  larger  paper  addressing  the  wider  governance  issues  for  BMMP.  For 
a  more  extensive  discussion  of  responsibilities  see  the  full  paper. 
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iv.  Exercise  of  a  common  set  of  procedures  for: 

•  Ensuring  an  appropriate  level  of  review  within  DoD 

•  Making  certifications  in  accordance  with  the  conditions  for  the  obligations  of 
funds 

•  Utilizing  decision  criteria,  including  standards,  requirements,  and  priorities 
that  result  in  the  integration  of  defense  business  systems. 

d.  The  COIs  are  responsible  for: 

i.  Analyzing  and  resolving  issues  relevant  to  each  community,  including  where 
appropriate,  the  drafting  of  Memoranda  of  Agreements  (MOAs),  Service  Level 
Agreements  (SLAs),  or  similar  mechanisms  for  defining  the  relationships  across 
organizational  or  federated  boundaries,  covering  matters  such  as  data,  meta-data, 
services,  interface  protocols,  access  rights,  ownership,  and  performance  levels; 

ii.  Reporting  through  the  appropriate  TSO  Assistant  Deputy  Director  (ADD)  to  the 
DBSMC  or  to  the  AAs  the  results  of  their  assessments. 

e.  The  Components  and  CBM  leaders  will: 

i.  Further  develop  their  mission-oriented  architectures  and  transition  plans  consistent 
with  the  BEA-BMA,  the  BTP-BMA  ,  and  the  rules  of  federation; 

ii.  Register  the  “To  Be”  architectural  products  or  as  built  blue  prints  in  the  BMA 
architectural  registry; 

iii.  Working  through  their  PEOs/PMs,  take  responsibility  to  assure  that  their 
architectures  and  transition  plans  result  in  solutions  that: 

•  Satisfy  mission  capabilities 

•  Are  consistent  with  the  BEA-BMA 

•  Are  consistent  with  BMA  rules  of  federation; 

iv.  For  systems  or  applications  that  may  have  potential  for  reuse,  register  those 
templates  in  the  BMA  template  registry; 

v.  CBM  leaders  will  also  proactively  collaborate  to  integrate  their  mission  oriented 
architecture  products  into  the  BEA-DoD  so  that  it  provides  a  single  architectural 
representation  of  the  capabilities  and  supporting  programs  for  which  the  AAs  are 
responsible. 

f.  The  OBT-TSO  will: 

i.  Support  the  DBSMC,  the  TCG,  the  AAs,  the  IRBs,  the  BMMP-PEO,  and,  when  so 
directed,  to  assist  other  BEA  and  BTP  stakeholders,  in  technical,  analytical,  and 
administrative  matters  including  but  not  limited  to: 

•  Developing,  assimilating,  consolidating  and  maintaining  the  BEA,  the  BTP 
and  the  Program  Baseline 

•  Developing  architecture  and  transitions  plan  components 

•  Assessing  for  compliance  all  appropriate  technical  and  policy  requirements 

•  Gathering  and  analyzing  the  necessary  data  and  preparing  reports  as  required, 
and  serving  as  the  liaison  with  the  Executive  and  Legislative  branches 
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•  Executing  communications,  public  affairs  and  outreach; 

ii.  Under  direction  from  the  DBSMC  establish  and  chair  the  BMA  Architecture 
Council,  composed  of: 

•  BMMP  Chief  Architect  (TSO) 

•  Services  Chief  Architects 

•  Stakeholder  Agency  Chief  Architects 

•  CBM  Representatives 

•  BMMP-PEO  Representative 

iii.  Assess  the  need  for  and  establish  as  required  review  boards,  including: 

•  In  collaboration  with  federation  entities,  appointing  board  members 

•  Appointing  the  board  chairs 

•  Approving  the  board  charters; 

iv.  Assess  the  need  for,  establish  and  register  COIs  as  required,  including: 

•  In  collaboration  with  federation  entities,  appointing  COI  members 

•  Appointing  the  COI  chairs 

•  Approving  the  COI  charters; 

v.  Evaluate  and  present  possible  options  upon  presentation  of  requested  variances  or 
cross-mission  conflicts;  and 

vi.  Consistent  with  the  rules  of  federation  and  directives  of  ASD  (NII)/DoD  CIO, 
maintain  the  several  registry  repositories  of  potential  interest  to  all  BMA  and  other 
GIG  participants.  (Note  that  in  some  instances  it  will  be  more  appropriate  for  some 
registries  to  be  maintained  at  a  lower  level  in  the  federation  because  it  is  of  interest 
to  a  narrower  range  of  participants.) 

g.  The  OBT  BMMP-PEO  will: 

i.  Based  on  guidance  from  CBM  leaders  be  responsible  for  developing  the  BEA- 
DoD,  and  the  BTP-DoD; 

ii.  Be  responsible  for  implementing  systems  deemed  to  be  part  of  the  DoD-wide 
federation  member. 
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GLOSSARY 


Capability.  The  ability  to  execute  a  specified  course  of  action.  It  is  defined  by  an  operational  user 
and  expressed  in  broad  operational  terms.  A  capability  includes  the  doctrine,  organization, 
training,  materiel,  leadership  and  education,  personnel,  and  facilities  required  to  achieve  a 
specified  course  of  action. 


Communities  of  Interest  (COI)16.  The  inclusive  term  used  to  describe  collaborative  groups  of 
users,  who  must  exchange  information  in  pursuit  of  their  shared  goals,  interests,  missions,  or 
business  processes,  and  who,  therefore  must  have  shared  vocabulary  for  the  information  they 
exchange. 


Configuration  Management.  A  discipline  applying  technical  and  administrative  direction  and 
surveillance  to:  (1)  identify  and  document  the  functional  and  physical  characteristics  of  a 
configuration  item;  (2)  control  changes  to  those  characteristics;  and  (3)  record  and  report  changes 
to  processing  and  implementation  status. 


Data.  A  representation  of  facts,  concepts,  or  instructions  in  a  formalized  manner  suitable  for 
communication,  interpretation,  or  processing  by  humans  or  by  automatic  means.  Data  and 
information  are  equivalent  terms  for  the  purposes  of  this  document. 

Data  Asset.  Any  entity  that  is  comprised  of  data.  For  example,  a  database  is  a  data  asset  that  is 
comprised  of  data  records.  A  data  asset  may  be  a  system  or  application  output  file,  database, 
document,  or  web  page.  A  data  asset  also  includes  a  service  that  may  be  provided  to  access  data 
from  an  application.  For  example,  a  service  that  returns  individual  records  from  a  database  would 
be  a  data  asset.  Similarly,  a  web  site  that  returns  data  in  response  to  specific  queries  would  be  a 
data  asset.  A  human,  system,  or  application  may  create  a  data  asset. 


Enterprise  Information  Environment  Mission  Area.  The  Department  of  Defense’s  Mission 
Area  responsible  for  managing  the  part  of  the  DoD  portfolio  known  as  the  enterprise  information 
environment  (EIE),  which  is  the  common,  integrated  computing  and  communications 
environment  of  the  GIG.  The  EIE  is  composed  of  GIG  assets  that  operate  as,  or  that  assure,  local 
area  networks,  campus  area  networks,  tactical  networks,  operational  area  networks,  metropolitan 
area  networks,  and  wide  area  networks.  The  EIE  is  also  composed  of  GIG  assets  that  operate  as, 
or  that  assure,  end  user  devices,  workstations,  and  servers  that  provide  local,  organizational, 
regional,  or  global  computing  capabilities.  The  EIE  includes  all  software  associated  with  the 
operation  of  EIE  assets  and  the  development  environments  and  user  productivity  tools  used  in  the 
GIG.  The  EIE  includes  a  common  set  of  enterprise  services,  called  Net-Centric  Enterprise 
Services  (NCES),  which  provide  awareness  of,  access  to,  and  delivery  of  information  on  the  GIG. 


16  For  details  see  “DoD  Net-Centric  Data  Strategy”,  DoD  CIO  (9  May  2003). 
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Global  Information  Grid  (GIG).  The  globally  connected,  end-to-end  set  of  information 
capabilities,  associated  processes,  and  personnel  for  collecting,  processing,  storing, 
disseminating,  and  managing  information  on  demand  to  warfighters,  policy  makers,  and  support 
personnel. 


Information  Assurance  (IA).  Information  operations  that  protect  and  defend  information  and 
information  systems  by  ensuring  their  availability,  integrity,  authentication,  confidentiality,  and 
non-repudiation.  This  includes  providing  for 

restoration  of  information  systems  by  incorporating  protection,  detection,  and  reaction 
capabilities. 


Information  Technology  (IT).  Any  equipment  or  interconnected  system  or  subsystem  of 
equipment  that  is  used  in  the  automatic  acquisition,  storage,  manipulation,  management, 
movement,  control,  display,  switching,  interchange,  transmission,  or  reception  of  data  or 
information  by  the  DoD  Component.  The  term  “information  technology”  includes  computers, 
ancillary  equipment,  software,  firmware  and  similar  procedures,  services  (including  support 
services),  and  related  sources. 


Interoperability.  The  ability  of  systems,  units,  or  forces  to  provide  data, information,  materiel, 
and  services  to  and  accept  the  same  from  other  systems,  units,  or  forces  and  to  use  the  data, 
information,  materiel,  and  services  so  exchanged  to  enable  them  to  operate  effectively  together. 
IT  and  NSS  interoperability  includes  both  the  technical  exchange  of  information  and  the  end-to- 
end  operational  effectiveness  of  that  exchange  of  information  as  required  for  mission 
accomplishment.  Interoperability  is  more  than  just  information  exchange.  It  includes  systems, 
processes,  procedures,  organizations  and  missions  over  the  life  cycle  and  must  be  balanced  with 
information  assurance. 

Key  Performance  Parameters  (KPPs).  Those  minimum  attributes  or  characteristics  considered 
most  essential  for  an  effective  military  capability.  KPPs  are  validated  by  the  Chairman  of  the 
Joint  Chiefs  of  Staff. 


Metadata.  Information  describing  the  characteristics  of  data;  data  or  information  about  data;  or 
descriptive  information  about  an  entity’s  data,  data  activities,  systems,  and  holdings.  For 
example,  discovery  metadata  is  a  type  of  metadata  that  allows  data  assets  to  be  found  using 
enterprise  search  capabilities. 

Metadata  Registry.  Repository  of  all  metadata  related  to  data  structures,  models,  dictionaries, 
taxonomies,  schema,  and  other  engineering  artifacts  that  are  used  to  support  interoperability  and 
understanding  through  semantic  and  structural  information  about  the  data.  A  federated  metadata 
registry  is  one  in  which  multiple  registries  are  joined  electronically  through  a  common  interface 
and  exchange  structure,  thereby  effecting  a  common  registry. 

Mission  Area.  A  defined  area  of  responsibility  with  functions  and  processes  that  contribute  to 
mission  accomplishment. 
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Net-Centric.  Relating  to  or  representing  the  attributes  of  net-centricity.  Net-  centricity  is  a  robust, 
globally  interconnected  network  environment  (including  infrastructure,  systems,  processes,  and 
people)  in  which  data  is  shared  timely  and  seamlessly  among  users,  applications,  and  platforms. 

Net-Centric  Enterprise  Services  (NCES).  A  DISA  program  to  implement  key  enabling 
capabilities  for  a  net-centric  enterprise.  NCES  will  provide  a  common  set  of  interoperable 
information  capabilities  in  the  Global  Information  Grid  (GIG)  to  access,  collect,  process,  store, 
disseminate,  and  manage  information  on  demand  for  warfighters,  policy  makers,  and  support 
organizations. 

Net-Centric  Operations  and  Warfare  (NCOW)  Reference  Model  (RM).  The  NCOW-RM 
describes  the  activities  required  to  establish,  use,  operate,  and  manage  the  net-centric  enterprise 
information  environment  to  include:  the  generic  user-interface,  the  intelligent-assistant 
capabilities,  the  net-centric  service  capabilities  (core  services,  Community  of  Interest  services, 
and  environment  control  services),  and  the  enterprise  management  components.  It  also  describes 
a  selected  set  of  key  standards  that  shall  be  needed  as  the  NCOW  capabilities  of  the  GIG  are 
realized. 

Net-Ready.  The  continuous  ability  to  interface  and  interoperate  to  achieve  operationally  secure 
exchanges  of  information  in  conformance  with  enterprise  constraints.  The  NR-KPP  assesses  the 
net-ready  attributes  required  for  both  the  technical  exchange  of  information  and  the  end-to-end 
operational  effectiveness  of  that  exchange. 

Net-Ready  Key  Performance  Parameter  (NR-KPP).  The  NR-KPP  assesses  information 
needs,  information  timeliness,  information  assurance,  and  net-ready  attributes  required  for  both 
the  technical  exchange  of  information  and  the  end-to-end  operational  effectiveness  of  that 
exchange.  The  NR-KPP  consists  of  verifiable  performance  measures  and  associated  metrics 
required  to  evaluate  the  timely,  accurate,  and  complete  exchange  and  use  of  information  to  satisfy 
information  needs  for  a  given  capability.  The  NR-KPP  is  comprised  of  the  following  elements: 

-  Compliance  with  the  NCOW  RM 

-  Compliance  with  applicable  GIG  Key  Interface  Profiles 

-  Verification  of  compliance  with  DoD  information  assurance  requirements 

-  Supporting  integrated  architecture  products  required  to  assess  information 
exchange  and  use  for  a  given  capability. 
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BEA  Relevant  Discussion  Areas 


This  paper  was  prepared  in  response  to  a  number  of  questions  on  the  issue  of  federation 
and  integration  raised  by  the  BEA  chief  architect.  The  paper  also  has  attached  a  DoD 
Architecture  Strategic  Plan  2004  to  2007,  prepared  by  Truman  Parmele  of  the  ASD(NII) 
office.  The  paper  and  the  attachment  were  discussed  during  a  two  hour  session. 
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IDA  15  Aug  2005 


BEA  Relevant  Discussion  Areas 


1 .  Characterize  the  differences  between  Integrated  and  Federated. 

a.  Upon  reviewing  DoD  and  CJCS  directives,  instructions  and  manuals,  this 
comparison  was  expanded  to  include  Interoperability.  This  was  in  part  due 
to  the  fact  that  the  term  “integrated”  alone  was  not  defined  anywhere; 
however,  “Integrated  Architecture”  was  used  extensively  and  tended  to  refer 
to  DODAF  and  integrated  products.  Additionally  the  term  Integration  showed 
up  frequently  in  the  context  of  the  Joint  Capabilities  Integration  and 
Development  System  (JCIDS)  process.  Interoperable  and  interoperability 
were  used  much  more  extensively  and  are  defined  in  the  published  documents. 
Similarly,  Federated  was  not  defined  in  any  DoD  documents;  however, 
Federated  Architecture  is  defined  in  the  published  IRB  CONOPS. 

b.  Definitions: 


o  Integrate  (verb)  -  Source:  Webster’s  Ninth  New  Collegiate 
Dictionary 

(no  definition  found  in  DoD  documents) 

•  To  form,  coordinate  or  blend  into  a  functioning  or  unified  whole 

•  To  unite  with  something  else 

•  To  incorporate  into  a  larger  unit  Unite 

o  Integrated  Architecture 


•  Sources:  CJCSI  3 170.0 IE,  1 1  May  2005  and  DODD  4630.5,  5 
May  2004. 

An  architecture  consisting  of  multiple  views  or  perspectives 
(operational  view,  systems  view  and  technical  view)  that  facilitates 
integration  and  promotes 
interoperability  across 
capabilities  and  among  related 
integrated  architectures. 

•  [Note,  DODD  4630.5  goes  on  to 
describe  the  operational,  systems 
and  technical  standards  architecture  views.] 

o  Interoperability 


Structured  (e.g.,  DODAF) 
architecture  products  that 
facilitate 

•  Uniting 

•  Working  Together 

•  Sharing 


•  Source:  CJCSI  3170.01E,  11  May  2005. 

The  ability  of  systems,  units  or  forces  to  provide  data  information, 
material  and  services  to  and  accept  the  same  from  other  systems, 
units  or  forces  and  to  use  the  data,  information,  material  and 
services  so  exchanged  to  enable  them  to  operate  effectively 
together.  Information  technology  (IT)  and  National  Security 
Systems  (NSS)  interoperability  includes  both 
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the  technical  exchange  of 
information  and  the  end-to-end 
operational  effectiveness  of  that 
exchanged  information  as  required  for  mission  accomplishment. 

•  Source:  DODD  4630.5,  5  May  2004. 

[lead  in  same  as  above,  with  following  appended]  - 
Interoperability  is  more  than  just  information  exchange.  It 
includes  systems,  processes,  procedures,  organizations  and 
missions  over  the  life  cycle  and  must  be  balanced  with  information 
assurance. 

o  Federation  -  Source:  composite 
from  2  dictionaries:  Webster’s  Third 
New  International  Dictionary  and 
Encarta  World  English  Dictionary 

•  An  organization  entity 
composed  of  smaller  organizational  divisions  united  to  achieve  a 
common  goal,  within  which  the  smaller  divisions  retain  for 
themselves  control  over  local  matters. 

o  Federated  Architecture  -  Source:  IRB  CONOPS,  Signed  by  Mr.  Wynne, 
2  Jun  2005. 

•  An  approach  for  enterprise  architecture  development  that  is 
composed  of  a  set  of  coherent  but  distinct  entity  architectures;  the 
architectures  of  separate  members  of  the  federation.  The  members 
of  the  federation  participate  to  produce  an  interoperable, 
effectively  integrated  enterprise  architecture.  The  federation  sets 
the  overarching  rules  of  the  federated  architecture,  defining  the 
policies,  practices  and  legislation  to  be  followed,  as  well  as  the 
inter-federate  procedures  and  processes,  data  interchanges,  and 
interface  standards,  to  be  observed  by  all  members  of  the 
federation.  Each  federation  member  conforms  to  the  enterprise 
view  and  overarching  rules  of  the  federation  in  developing  its 
architecture.  Internal  to  themselves,  each  focuses  on  their  separate 
mission  and  architecture  that  support  that  mission. 

Effectively  Combines  All 

Approach  for  EA  development:  i 

•  Hierarchy  of  overarching  rules  to 
be  followed  by  members 

•  Distributed  control  over  local  ] 

matters 

•  Focus  on: 

•  Interoperability 

•  Integrated  Architecture  j 


A  way  for  organizations 
to  unite  with  distributed 
control  over  local  matters 


Work  together  and  give 
info/services/material 
to  one  another 
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c.  IDA  Comments: 


o  Integration  -  It  appears  that  the  term  integration  as  used  with  respect  to 
Information  Technology  business  systems,  not  defined  in  any  formal 
document,  is  perceived  by  many  to  imply  a  broad  ranging  (ERP-like) 
single  solution  as  an  appropriate  approach  to  transforming  the  DoD 
BMA. 

•  High  probability  that  this  is  the  primary  source  of  failures  in 
previous  attempts  to  transform  DoD  systems  over  the  years  (e.g., 
CIM). 

•  The  single  system  (all  encompassing)  solution  has  its  place  some 
times,  but  not  always  -  especially  in  very  large  organizations  such 
as  the  DoD. 

o  Federated  Architecture  -  Within  DoD  the  term  Federated  Architecture  has 
only  recently  come  into  vogue.  There  is  no  official  documentation 
describing  Federated  Architecture  in  detail.  This  has  left  a  void  allowing 
multiple  interpretations  on  the  part  of  stakeholder  communities. 
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2.  Characterize  Architecture  Compliance  from  3  perspectives: 

a.  System  certification  as  part  of  a  Federated  Architecture 

The  system  adheres  to  the  rules  of  the  Federation. 

b.  What  constitute  a  compliant  architecture 

A  compliant  architecture  conforms  to  the  rules,  constraints,  needs,  formats, 
etc  that  have  been  established  in  the  (then)  current  version  of  the  BEA. 

c.  Review  of  issued  policy:  IRB  CONOPS  and  recent  IRB  submission 
guidelines 

i.  NDAA  required  DoD  to  establish  an  investment  review  process 
incorporating  provisions:  (1)  for  the  review  and  approval  by  an  IRB; 
(2)  threshold  criteria  to  ensure  appropriate  review;  and  (3)  guidance 
consistency  issued  by  the  Secretary  of  Defense  and  the  DBSMC. 

•  This  has  been  accomplished 

(A)  with  the  formally  signed  IRB  CONOPS,  and 

(B)  is  further  being  extended  by  the  proposed  additional  IRB 
submission  guidelines  (DoD  Business  Systems  Investment 
Review  Proposal  Submission  Guidelines) 

•  The  IRB  process  stipulates  that  the  Approval  Authority  (AA) 
must  certify,  and  the  DBSMC  must  approve  this  certification, 
that  the  System  is  in  compliance  with  (conforms  to)  the 
Enterprise  Architecture18 

ii.  Standard  Set  of  IRB  Criteria  for  Certification  is  presented  as  Appendix 
E  of  the  “Investment  Review  Process  Overview  and  CONOPS  for 
IRB,  dated  17  May  2005,  and  signed  out  by  Mr.  Wynne  on  2  Jun  2005. 
The  criteria  is  segmented  in  4  major  groupings: 

1.  Basic  System  Information 

■  Provides  basic  system  information 

■  Focuses  on  funding  request,  budget  status,  and 
certification  request 

2.  Justification 


17  The  BEA  will  evolve  in  an  orderly  and  controlled  manner  under  the  supervision  of  the  DBSMC  to 
accommodate  changes  in  legislation,  policy,  capabilities  and  requirements,  technology,  etc. 

18  Compliance  is  one  of  3  approved  paths  for  obligations  in  excess  of  $  1M,  the  other  paths  are  that  the 
system 

•  is  necessary  to  achieve  a  critical  national  security  capability  or  address  a  critical  requirement  in  an 
area  such  as  safety  or  security,  or 

•  is  necessary  to  prevent  a  significant  adverse  effect  on  a  project  that  is  needed  to  achieve  an 
essential  capability,  taking  into  consideration  the  alternative  solutions  for  preventing  such  adverse 
effect 
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■  What  DoD  enterprise  or  component  specific 
requirements  this  investment  addresses 

■  What  policy,  law,  or  regulation  this  is  aligned 
with 

3.  Transition  Plan 

■  Identifies  how  investment  is  aligned  with 
Transition  Plan 

4.  Architecture: 

■  Identify  the  activities  or  processes  supported 

■  Identify  capabilities  /functions  encompassed 

■  Is  it  required  to  achieve  BE  A  objective?  If  so 
which  one? 

■  Is  it  compliant  with  BEA  and  Component  Arch 

■  Does  it  comply  with  technical  environment;  if 
not  is  it  part  of  the  migration  plan? 

■  Are  interfaces  identified  and  schedules  aligned? 

iii.  DoD  Business  Systems  Investment  Review  Proposal  Submission 
Guidelines  (Version  07  15  051  -  adds  more  definitive  guidance 

1 .  Attachment  A  -  guidance  for  completing  certification 
template 

■  AV-1,  TV-1  and  OV-5  not  required  for  FY05  - 
FY06  submissions 

■  States  “The  BEA  is  being  iteratively  developed. 
Please  contact  your  IRB  support  group  for 
specific  guidance” 

IDA  Comment:  Believe  it  will  be  relatively  easy  to  show  appropriate  linkage  to  BEA  in  this 
year’s  process;  however,  subsequent  years  likely  to  be  more  stringent. 

2.  Attachment  B  -  CBMA  BEA  Compliance 

■  “Until  BEA  3.0  is  complete  the  IRB  will  map 
systems  to  operational  activity  nodes  of 
emerging  BEA” 

IDA  Comment:  This  approach  will  likely  continue  as  a  minimum  compliance  condition. 

■  Current  required  standard  conditions  are  also 


listed  for  each  of  the  CBMAs 


IDA  Comment:  These  are  likely  to  be  the  most  visible  rules,  policies,  standards,  systems 
alignment  requirements,  and  constraints  for  the  IRBs. 

IDA  Comment:  Potential  Gaos  or  Weaknesses 

•  Provisions  addressing  IA,  Interoperability,  and  Net-Centric  Data 

Strategy  are  lacking. 

•  These  critical  areas  represent  extremely  important  rules,  policies, 
standards,  and  practices  that  should  be  embedded  in  BEA  as  it  evolves. 

•  Nil  has  a  major  leadership  role  to  address  these  gaps  /  weaknesses. 
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3.  How  to  proceed  with  Net-Centricity 

a.  The  Problem: 

i.  Evolution  of  the  GIG  is  continuing,  with  many  concepts  still 
undergoing  changes.  These  include 

o  Governance 

o  Net-Centric  Operations 

o  NCES 

o  Standards 

o  Architecture 

ii.  Simultaneously,  the  FEA-RM  is  also  evolving  and  under 
development,  leaving  many  details  not  fully  defined. 

iii.  This  conspires  to  make  explicit  technical  decisions  and  actions  based 
on  these  decisions  difficult  to  bring  to  fruition. 

o  Policy,  roles,  and  responsibility  issues  are  much  easier  to 
resolve  at  this  level  of  technical  adolescence  (See  e.g.,  Data 
Sharing  in  a  Net-Centric  DoD  -  DODD  8320.2,  2  Dec  2004). 

b.  Effect  on  BMMP: 

i.  High  probability  many  NCES  Services  will  be  inadequately  defined, 
and  not  available  when  needed  by  BMA  systems. 

ii.  The  FEA  Data  Reference  Model  and  the  DoD  Enterprise 
Architecture  Data  Reference  Model  have  insufficient  detail  to  define 
a  common  ontology  for  an  aligned  data  and  meta-data  description. 

c.  Suggested  Path  Forward  for  BMMP: 

i.  Identify  which  NCES  and  Data  issues  are  of  importance  to  the  BMA. 

o  Prioritize  these  items. 

o  Communicate  these  to  NIL 

o  Apply  pressure  where  possible. 

ii.  Support  the  development  of  “temporary”  workarounds  when  Nil  (or 
DIS  A)  has  not  made  available  a  necessary  service  or  standard. 

o  Be  prepared  to  migrate  to  the  “official”  service  or  standard 
when  it  becomes  available,  or 

o  Take  the  lead  to  make  the  BMA  “workaround”  the  “de  facto” 
service  or  standard. 

iii.  Participate  actively  in  the  various  working  groups  addressing  the 
NCES  and  standards  issues. 
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iv.  Work  aggressively  in  those  areas  which  are  mostly  independent  of 
the  GIG,  and  the  FEA-RM.  These  include: 

o  BEA  data  products  including  AV-2  and  OV-7. 

o  Resolve  semantic  agreement  issues  within  BMA. 

o  Identify  authoritative  data  sources. 

o  Specify  and  facilitate  implementation  of  Business  Enterprise 
Services  to  supplement  (or  extend)  those  provided  by  NCES 
specifically  for  BMA  needs. 
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Implementing  the  BEA;  The  Importance  of  the  Edge: 
Recommendations  for  (Enterprise  Level)  BMMP  Activities  -With  Notes 


This  briefing  evolved  from  discussions  and  a  paper  requested  by  the  chief  architect  as  a 
follow-up  to  the  paper  entitled  BEA  Relevant  Discussion  Areas.  IDA  was  asked  to 
expand  on  the  challenges  presented  and  for  suggestions  on  how  to  facilitate  business 
transformation.  This  briefing  contains  explanatory  notes,  which  are  important  to 
understanding  the  issues  discussed.  In  particular  see  the  bolded  paragraph  on  the  Title 
notes  page  indicating  that  the  focus  of  this  paper  is  the  instantiation  of  systems  within  a 
federated  context. 
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This  briefing  presents  some  of  the  ideas  contained  in  a  note  prepared  in 
response  to  a  request  by  Brian  Wilczynski  shortly  before  his  transfer  to  Nil. 

Brian  had  asked  IDA  to  comment  on  the  significant  risks  facing  BMMP  and  for 
suggestions  on  how  best  to  proceed  with  implementing  the  solution  products  for 
the  DoD  Business  Mission  Area  (BMA)  transformation.  In  this  briefing  ideas  are 
presented  to  help  establish  priorities  for  the  multitude  of  efforts  currently  ongoing 
in  order  to  optimize  the  investments  made  to  facilitate  the  transformation. 


The  theme  of  this  briefing  is  NOT  the  BEA  and  its 
evolution  —  a  very  important  issue  —  but  rather  the 
instantiation  of  the  systems  and  programs  that  actually 
effect  the  desired  business  transformation. 


Throughout  this  briefing,  the  term  “solution  systems  and  programs”  is  used  to 
reference  those  products. 
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Agenda 

•  Critical  Areas  Relevant  to  BMA  Transformation 

-  Essential  Elements 

-  Participating  Entities 

-  Infrastructure 

-  Core  Enterprise  Services  (NCES) 

-  Business  Mission  Area  Services 

-  Data 

-  Systems  /  Programs 

•  Priorities  and  Approaches  to  Facilitate  BMA  Transformation 

-  Work  at  the  Edge 

-  Work  on  the  Basics 

-  Defining  the  Priorities 

-  Attracting  Cooperation  from  the  Community 
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Approach:  As  a  baseline  to  this  assessment,  we  identify  and  characterize  critical 
areas  relevant  to  BMA  transformation.  From  this  perspective,  we  then  identify 
approaches  to  facilitate  the  BMA  transformation. 
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Critical  Areas  Relevant  to  BMA 
Transformation 
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Essential  Elements  of  IS 

•  Infrastructure 

•  Core  Enterprise  Services  (NCES) 

•  Business  Mission  Area  Services 

•  Data 

•  Systems  /  Programs 


All  these  elements  require  a  set  of  common  policies,  practices,  etc.  —  in 
in  general  an  overall  governance  structure.  This  is  particularly  important 
when  the  implementation  of  the  information  systems  are  performed  with 
a  Federated  approach. 
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For  the  purposes  of  this  discussion,  we  identify  a  number  of  basic  elements  of 
the  Information  Systems  (IS)  facilitating  the  BMA  transformation.  Categorizing 
these  basic  elements  is  somewhat  arbitrary  and  may  well  be  perceived 
differently  depending  upon  the  viewer’s  level  of  abstraction.  However,  the 
following  list  spans  the  necessary  elements,  all  of  which  fall  within  the  Global 
Information  Grid  (GIG).[1] 

[11  These  are  not  quite  aligned  with  current  GIG  /  NCES  nomenclature. 
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Participating  Entities 

•  Approval  Authorities  (AA) 

•  NII/DISA,  NSA 

•  BMMP;  TSO 

•  CBMs 

•  Components 

•  PMs/PEO 


In  all  cases  the  participation  of  the  appropriate  stakeholder  communities 

is  critical. 
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Note  that  the  Business  Transformation  Agency  (BTA)  is  included  here  as  a 
Component. 

Partial  or  incomplete  participation  of  all  interested  stakeholders  will  increase  the 
business  transformation  risks. 
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Infrastructure 

•  Discovery  supporting  elemental  sub-services,  e.g. 

-  Registration 

-  Cataloguing 

-  Directory 

-  Query 

-  Search 

•  Information  Assurance  (IA) 

•  Access  Control 

•  Process  Interface  Specs  (APIs) 

•  Information  Exchange  Package  Specs 

Hidden  parts  of  the  infrastructure  supporting  the  GIG  are  only  of  minor 

interest  here. 
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Included  in  the  infrastructure  are  all  the  truly  hidden  assets  and  services  that 
support  the  GIG.  These  include  the  communications  links,  the  support  hardware 
and  software  for  the  physical  communications  transport  and  the  networks 
supported  by  them.  Also  included  are  the  DISA  Defense  Enterprise  Computing 
Centers  (DECCs)  and  all  of  the  mission  specific  servers  across  the  Department. 
Where  data  is  stored,  processes  are  executed  and  connectivity  is  maintained, 
all  important  parts  of  the  infrastructure,  are  not  of  major  importance  to  this 
discussion. 
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Core  Enterprise  Services  (NCES) 

•  Discovery 

•  Security;  Trust  Authority  Mechanism 

•  Mediation 

•  Collaboration 

•  Messaging 

•  Storage  Services 

•  User  Assistance 

•  Enterprise  Systems  Management 

Note  that  the  NCES  roadmap  —  the  responsibility  of  Nil  —  stretches  from 
FY2004  through  FY2009,  at  an  estimated  cost  of  $380M. 
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The  effort  to  instantiate  the  NCES  is  very  large,  and  as  the  roadmap  indicates 
will  not  be  completed  (optimistically)  before  the  end  of  FY2009.  Therefore  some 
of  the  essential  NCES  will  not  be  available  as  the  first  sets  of  transformation 
solution  systems  and  programs  roll  out.  This  will  entail  some  work-arounds  on 
the  part  of  the  PMs  responsible  for  the  early  solution  systems  and  programs. 
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Business  Mission  Area  Services 

•  Financial  Management  (FM)  has  initiated 

-  Standard  Financial  Information  Structure  (SFIS) 

-  Financial  Management  Enterprise  Services  (FMES) 

-  DFAS  Corporate  Database  (DCD)  and  DFAS  Corporate  Warehouse  (DCW) 

-  Business  Enterprise  Information  Services  (BEIS),  including 

•  Business  Intelligence  (Bl) 

•  Defense  Department  Reporting  System  (DDRS) 

•  Other  Core  Business  Mission  (CBM)  Actions 

-  Potentially  the  four  other  CBMs  will  define  additional  business  oriented 
services  appropriate  to  each  of  their  missions 

•  May  be  included  in  BEIS  or  instantiated  as  a  separate  set  of  services 

•  Bl  and  DDRS  services  could  be  extended  to  include  needs  of  all  CBMs 

•  Also  a  wide  area  workflow  requirement  will  be  ubiquitous 
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Business  transformation  will  be  facilitated  by  broad  endorsement  and  early 
adoption  of  essential  business  oriented  services  and  standards  that  are 
perceived  by  the  community  to  ease  rather  than  to  burden  their  efforts.  The 
examples  listed  here  should  have  the  necessary  characteristics.  But  they  must 
be  socialized  across  the  community  as  early  as  possible. 
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Data 

•  Semantics:  vocabulary,  taxonomy,  ontology 

-  AV-2  part  of  the  solution 

•  Metadata  description  of  the  data  characteristics 

-  Need  an  appropriate  taxonomy  for  each  community 

•  Identification  of  the  “Authentic  Source”  —  the  data  “owner” 

-  Identification  of  “Data  Steward”;  not  necessarily  the  data  owner 

•  Data  exchange  mechanisms  (see  Infrastructure) 

-  With  legacy  data 

-  With  “To  Be”  databases 

-  OV-7,  OV-3,  SV-6,  (SV-1,  SV-3)  part  of  the  solution 

The  magnitude  of  the  data  problem  is  immense.  Consequently,  especially  here, 
an  incremental  approach  must  be  taken. 
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Most  required  data  exists  (usually  in  multiple,  not  necessarily  consistent 
databases).  There  are  many  ambiguities,  definitional  conflicts  and  frequently 
unambiguous  transformations  are  not  possible. 
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Systems  /  Programs 

•  The  solution  products  that  actually  facilitate  the 
desired  Department  business  transformation 

-  Responsibility  of  the  Components;  including  the  BTA 

•  Supported  by  GIG  infrastructure  and  services 
and  CBM  services 

•  Here  the  Federated  approach  provides  for  an 
interoperable  set  of  systems  developed  by  the 
Components  focused  on  their  specific  missions 
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Early  application  and  demonstration  of  tiered  responsibility  using  federated 
approaches  will  facilitate  coherent  system  and  program  instantiations,  help 
mitigate  boundary  issues  and  foster  successful  business  transformation.  If 
orchestrated  with  care  this  should  lead  to  an  accelerating  interest  in  coherence 
amongst  the  Components,  rather  than  the  historical  parochial  NIH  approach, 
that  has  always  resulted  in  stovepipes. 


A  major  caution  is  to  limit  the  imposed  rules  of  federation  to  the  absolute 
minimum  to  achieve  the  required  interoperability  across  the  Department. 
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Priorities  and  Approaches  to  Facilitate 
BMA  Transformation 
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Work  at  the  Edge 

•  Specify  at  the  edge  services  provided  at  the  NCES  or  BMA 
level  long  before  adequate  specifications  have  been 
developed  for  the  funding  and  acquisition  of  the  product 

-  Define  interface  specifications;  do  so  as  generically  as  possible  to 
accommodate  as  many  as  possible  functions  for  that  product 

-  Do  this  with  enough  specificity  so  that  application  developers  can  potentially 
take  advantage  of  that  service  or  interface  as  their  product  specifications  are 
being  developed 

-  If  the  service  of  interest  is  not  yet  available  when  the  application  product 
requires  it,  a  workaround  can  be  substituted  and  used  until  the  fully 
engineered  service  product  does  become  available 

-  Since  the  calling  sequence,  e.g.  an  API,  was  defined  and  well  known  early-on 
(and  the  workaround  used  the  same  API),  plugging-in  the  new  service  module 
should  require  only  modest  effort 

•  Elements  where  this  approach  apparently  is  not  now  being 
used,  but  where  it  should  be,  include 

-  Process  Interface  Specs  (APIs) 

-  Infrastructure  Information  Exchange  Package  Specs 
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A  wonderful  example  of  this  approach  is  the  7-Layer  OSI  Model  developed  for 
networks  and  in  use  today  for  the  Internet.  Here  the  interface  standards  for  each 
of  the  7-layers  were  specified  early-on.  This  allows  for  different  modules  to  be 
embedded  at  any  of  the  7-layers  to  handle  different  protocols,  communications, 
etc.  Currently,  e.g.  IPv6  is  in  the  process  of  replacing  IPv4,  with  no  disruption  of 
ongoing  Internet  functionality. 

Another  example  is  the  GIG  System  Engineering  Net-Centric  Implementation 
Documents  (NCIDs)  being  developed  by  Mike  Kern  of  Nil  (  see  attached 
diagrams  in  Back-up).  Here  it  is  less  clear  that  the  interfaces  will  be  defined  and 
promulgated  before  all  the  modules  are  implemented. 

Note  that  in  some  cases  a  workaround  service  product  may  become  the  de  facto 
service  product.  This  is  a  very  good  approach  to  both  acquiring  the  service 
product  as  early  as  possible  and  also  as  a  mechanism  of  encouraging 
evolutionary  improvements  in  such  broadly  used  services. 
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Work  on  the  Basics 

•  Data 

-  Semantics:  vocabulary,  taxonomy,  ontology 

-  Registration  of  the  data  and  the  metadata 

-  Identification  of  the  “data  owners”  and  “data  stewards” 

-  Metadata  description  of  the  characteristics  of  the  data 

•  Nil  ought  to  be  more  aggressive  in  promulgating  the  use  of  XML 
and  (arbitrarily  if  necessary)  selecting  a  tool  for  developing  schemas 

•  Governance 

-  Roles  and  responsibilities 

-  Rules  of  Federation 

These  can  be  approached  entirely  within  the  BMA,  independent  of 
efforts  by  Nil  and  the  GIG  more  generally. 
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These  are  quite  basic  issues,  that  should  be  approached  with  greater  vigor  then 
heretofore.  Note  that  these  apply  both  within  the  BMA  and  the  larger  GIG 
environment. 
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Defining  the  Priorities 

•  Primarily  the  responsibility  of  the  CBM  leaders 

-  Collectively  and  individually  as  appropriate 

•  Within  BMA,  the  FM  has  embarked  in  a  well 
defined  course  of  action  —  the  BEIS,  including 
initial  and  follow-on  increments 

-  FM  is  encouraged  to  adopt  recommendations  presented  here 

-  Other  CBMs  encouraged  to  emulate  FM  actions 

•  CBM  leaders  collectively  should  provide  Nil  with 
BMA  priorities  for  NCES  availability 

•  Nil  should  be  encouraged  to  embrace 
recommendations  presented  here 
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The  approach  to  be  taken  should  follow  the  latest  strategy  and  philosophy  that 
ultimately  led  to  the  development  of  the  successful  BEA  3.0,  i.e.  focus  on  the 
current  priorities  (BEPs)  and  address  warfighter  needs. 
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Attracting  Cooperation  from  the 

Community 

•  Involve  community  representation  at  appropriate 
junctures  in  the  decision  processes 

•  As  early  as  possible  deliver  a  service  or  product 
that  the  community  finds  assists  in  their  missions 

•  As  the  “edges”  and  the  “basics”  are  defined  and 
as  products  are  ready  for  release  communicate 
these  as  clearly  and  widely  as  possible 

•  Do  not  place  burdens  on  the  legacy  Program 
Managers  for  temporary  interfaces  to  legacy 
data;  the  burden  should  be  borne  by  the  “To  Be” 
systems  Program  Managers 
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Do  not  repeat  the  errors  of  the  early  days  of  the  BMMP  BMSI.  TSO’s  role  is  not 
that  of  a  Program  Manager.  Rather  it  has  a  very  important  coordinating, 
technical  support,  integrating  and  communications  role  to  play.  Orchestrate  the 
efforts  of  the  Components  to  delineate  the  issues  of  importance  and  to  associate 
into  “Communities  of  interest”  (COIs). 


Note,  that  for  some  reason  the  term  COI  appears  to  be  a  problem  within  BMMP. 
Unless  something  has  changed  in  recent  months,  that  is  the  term  that  Nil  has 
been  using  to  identify  DoD  entities  across  the  Department  with  similar  IT 
interests. 

In  any  case  such  groups  may  or  may  not  mean  the  same  thing  as  the 
“Component  Working  Groups,”  now  under  discussion  in  TSO.  Some  potential 
definitional  problem  here  ought  to  be  resolved. 
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Back-up 
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GIG  Functionality  and  Performance 
Requirements  are  Not  Complete 


Enterprise  Architectural 
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Here  the  Nil  NCIDS  team  (under  Mike  Kern)  has  clearly  indicated  that 
there  is  a  “missing  link”  between  the  GIG  and  the  solution  systems  and 
programs.  In  this  example,  the  issue  is  the  required  systems  engineering 
linkages.  But  in  a  parallel  scenario  pertaining  to  business  transformation, 
a  “missing  link”  exists  between  the  services  provided  by  the  GIG  NCES 
and  the  solution  systems  and  programs  utilizing  those  services.  But  see 
next  diagram. 


Initial  NCID  Document  Tree 


lmportance_of_the_Edg  DRAFT 

e-0ct2005.ppt 


As  shown  here,  the  NCIDS  team  has  identified  the  required  “missing  links”  in  the 
systems  engineering  arena  in  great  detail.  But  it  is  a  major  undertaking  to 
instantiate  all  the  processes  shown  here. 


The  theme  presented  in  this  briefing  is  that  initially  (as  early  as  possible)  define 
only  the  interfaces  at  the  top  and  the  bottom  of  the  “missing  link”  shown  in  the 
previous  diagram,  i.e.  “work  at  the  edge.”  In  that  way,  the  PMs  providing  the 
several  NCES  services  of  the  NCES  and  the  PMs  developing  the  solution 
systems  and  programs  can  be  working  on  their  respective  systems  in  parallel. 
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Architecture  Federation-  Some  of  the  Issues 


This  briefing  was  presented  to  a  Federation  Working  Group,  chaired  by  the  BE  A  Chief 
Architect. 
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Architecture  Federation- 
Some  of  the  Issues 

Al  Brenner 
IDA 

October  25,  2005 


Federation 

•  Definition  -  An  organizational  entity  composed  of  smaller  organizational 
divisions  united  to  achieve  a  common  goal,  within  which  the  smaller 
divisions  retain  for  themselves  control  over  local  matters 

•  DoD  is  organized  as  a  federation  —  Components  have  a  degree  of 
independence  to  better  accomplish  their  respective  missions 

•  To  achieve  modern,  interoperable  IS  among  all  functions  and  all 
Components  is  an  enormous  challenge 

•  The  GIG  itself  is  an  IS  federation  consisting  of  3  (+1)  members 

-  Warfighter  Mission  Area 

-  Intelligence  Mission  Area 

-  Business  Mission  Area 

-  Enterprise  Information  Environment  infrastructure  Mission  Area 

•  These  entities  ,  e.g.  BMA,  are  further  partitioned  into  federation  elements 

•  Aligning  IS  architecture  development  efforts  with  the  organizational 
structure  of  the  DoD  maximizes  the  probability  of  success 


Federated  Architecture 

•  Definition  —  An  approach  for  enterprise  architecture  development  that  is 
composed  of  a  set  of  coherent  but  distinct  entity  architectures;  the 
architectures  of  the  separate  members  of  the  federation  (See  ETP) 

•  Apart  from  definitions  in  the  ETP  and  the  IRB  CONOPS  glossaries,  there 
is  no  detailed  elucidation  of  the  term 

-  There  is  wide  diversity  of  understanding  of  the  term  within  the  community 

•  A  federated  architecture  CONOPS  exists  in  Draft  form 

-  It  is  being  further  refined 

-  It  should  be  coordinated,  approved,  and  widely  disseminated 

•  A  set  of  “Bylaws”  guiding  the  federated  architecture  approach  is  crucial 
for  a  successful  set  of  application  products,  i.e.  systems  and  programs, 
to  result  from  this  approach 

•  The  object  is  to  attain  interoperability  amongst  the  federated  entity 
architectures,  resulting  in  an  effective  “integrated  architecture” 

-  Consistent  with  policy  and  other  constraints,  while  minimizing  the  burden  in 
the  development  of  the  resulting  program  products 


Federated  Architecture  Bylaws  —  Requirements 

•  Definitions 

•  Key  Operational  Principles 

•  Governance,  including  entity  roles  and  responsibilities 

•  Scope  of  actions  and  controls 

•  Establish  a  Data  Strategy,  including 

-  Data  semantics:  vocabulary,  taxonomy,  ontology 

-  Data  and  metadata  definition  and  registration  procedures 

-  Data  exchange  mechanisms 

-  Specifications  for  data  accuracy,  reliability  and  timeliness 

-  Identification  of  “data  owners”  and  “data  stewards” 

•  Establish  inter-federate  procedures  and  processes,  including 

-  Process  exchange  specifications 

-  Identification  of  shared  business  processes 

•  Policy  statement  on  alignment  with  other  DoD  and  federal 
architectures,  e.g. 

-  GIG  and  its  net-centric  environment,  NCES,  etc. 

-  FEA-RM 
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Parallel  of  DoD  and  e-Biz  World  Needs 

•  The  rapidly  expanding  e-business  world  is  a  loosely  coupled  federation  and 
can  be  characterized  as 

-  Participating  companies  want  to  interact  with  all  others 

-  But  want  independence  to  do  it  their  way  —  to  protect  their  trade  secrets 

•  DoD  is  a  slightly  more  tightly  coupled  federation  —  but  not  by  much 

-  Each  Component  wants  independence  to  optimize  their  mission  performance 

-  But  all  understand  and  policy  dictates  the  need  to  interoperate 

•  The  diversity  of  corporate  entities  participating  in  developing  capabilities  to 
accomplish  these  ends  is  driving  a  quite  coherent  approach,  allowing  for 

-  Heterogeneity,  interoperability,  and  ever  changing  requirements 

-  With  characteristics  which  are 

•  Location  transparent 

•  Loosely  coupled 

<  Protocol  independent 

•  BMMP  should  take  advantage  of  these  “best  practices” 


The  Basic  Approach 

•  The  client-server  paradigm  has  evolved  with  the  maturation  of  the  web 

-  First  into  a  web-based  object-oriented  paradigm 

-  Now  into  a  web  service-based  paradigm  —  service  oriented  architecture  (SOA) 

•  SOA  brings  into  play  the  tools  required  for  a  successful  federated  approach 

-  It  is  consistent  with  current  net-centric  doctrine 

-  It  is  consistent  with  the  BEA 

•  The  basic  ideas  are  all  open  source,  i.e.  non-proprietary 

•  Several  large  consortia  of  commercial,  academic,  and  government 
participants  are  promoting  the  approach,  including 

-  World  Wide  Web  Consortium  (W3C) 

-  Open  Application  Group  (OAGi) 

-  OASIS 

-  Liberty  Alliance  Project 

•  BMMP  leadership  is  required  to  coordinate  the  development  and  to  specify 
the  details  of  how  to  organize  these  technologies 
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Some  Important  BMA  Activities 

•  Many  CBM  and  Component  entities  are  engaged  in  developing 
approaches  consistent  with  this  theme 

•  A  good  example  is  the  FM  intensive  activity  to  develop  a  Data  and 
Services  Implementation  Plan  to  support  the  instantiation  of  the  SFIS;  see 

-  Standard  Financial  Information  Structure  (SFIS)  CONOPS  v2.4  (19Sept2005) 

-  BMA  Data  and  Services  Implementation  Plan;  Initial  Net-Centric  Steps  for  SFIS  vl.O 
Briefing  (26August2005) 

•  Another  FM  initiative  is  the  development  of  the  Business  Enterprise 
Services  (BEIS),  which  in  addition  to  financial  services,  includes  a  DFAS 
Corporate  Database  (DCD)  and  a  DFAS  Corporate  Warehouse  (DCW) 

•  Other  important  BMMP  references  include 

-  BMA  Net-Centric  Strategy  v4.0  (29March2005) 

-  Federated  Business  Enterprise  Architecture  CONOPS  v0.9c  Draft  (5July2005) 

-  Collaborative  Architecture  Development  Environment  (CADE)  CONOPS  v2.0  Draft 
(9Sept2005) 

-  Architecture  Development  Methodology  (ADM)  for  the  Federated  BEA  vl.O  (15 
August2005) 


Some  Issues 

•  The  Good  News 

-  Nil  has  major  responsibilities  to  provide  infrastructure  and  services 

-  The  current  SOA  approach  is  only  beginning  to  mature;  there  are  few  deep- 
seated  commitments  yet  made  by  the  federate  members 

-  There  are  a  number  of  very  positive  activities  underway  within  the  BMA 
community 

•  The  Bad  News 

-  Nil  is  unlikely  to  deliver  many  of  its  products  in  a  timely  manner;  e.g.  the 
NCES  roadmap  extends  through  FY2009  at  a  cost  of  $380M 

-  The  several  BMA  activities  appear  not  to  be  interacting  holistically 


The  proposal  is  to  focus  BMMP  effort  into  coordinating  the 
development  of  the  BMA  federated  Bylaws 
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Comments  on  “No  Such  Thing  as  Federated  Architecture” 


This  paper  was  prepared  in  response  to  an  invitation  for  IDA’s  comments  on  the  meaning 
of  “federated  architecture”  from  Brian  Wilczynski,  ASD(NII),  chair  of  the  Federated 
Joint  Architecture  Working  Group,  who  was  engaged  in  an  e-mail  discussion  with  two  of 
his  support  contractors  on  that  subject. 
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A1  Brenner  1/9/2006 


Comments  on  “No  Such  Thing  as  Federated  Architecture” 

A  bit  belatedly,  I  am  responding  to  Brian’s  request  that  I  join  in  on  this  interesting 
discussion.  Let  me  start  by  saying  that  I  agree  with  much  of  the  explanation  of  the 
continuing  dialogue,  initiated  by  Alex  late  Thursday,  January  5,  and  especially  in  his 
message  of  this  past  Saturday  morning.  But  contrary  to  his  indication  in  his  last  message, 

I  do  believe  that  much  of  the  difficulty  in  these  discussions  —  not  only  here,  but 
throughout  DoD  —  is  in  the  definition  of  terms.  Indeed  much  of  the  discussion  amongst 
this  small  group  of  experts  arises  from  ill-defined  terminology.  Think  of  the  problem  that 
presents  to  the  much  larger  community,  which  must  design,  develop,  acquire  and  oversee 
the  IS/IT  to  which  the  architecture  relates.  Let  me  elaborate  a  bit. 

The  DoDAF(vl.O)  in  Section  1.2  clearly  articulates  the  first  major  definitional  problem, 
to  wit  —  “the  term  architecture  is  generally  used  both  to  refer  to  an  architecture 
description  and  an  architecture  implementation .”  The  discussion  continues  to  indicate 
that  in  the  DoDAF  “the  term  architecture  will  be  used  as  a  shortened  reference  to 
architecture  description .”  But  of  course  as  Alex  indicates  you  don’t  really  federate  the 
architecture  description,  but  the  (architecture)  implementation  of  the  various 
architecture  descriptions.  It  is  the  implementations  —  I  prefer  the  instantiations  —  or  as 
Alex  and  the  community  calls  them,  the  systems,  that  are  federated. 

But  the  definition  of  terms  problem  permeates  a  much  larger  set  of  issues.  In  the  DoDAF, 
the  term  integrated  architecture  (Section  1.5)  is  defined  as  “an  architecture  description 
that  has  integrated  Operational,  Systems  and  Technical  Standards  Views.”  For  the 
architecture  description  of  some  system,  this  makes  good  sense,  whereas  I  believe  it  is 
inappropriate  and  unimplementable  if  applied  to  an  enterprise  level  architecture,  which 
invariably  means  something  like  a  system  of  systems  —  in  terms  even  broader  than  that 
introduced  by  Jeff  in  his  comments. 

I  did  not  participate  in  the  FJAWG,  nor  did  I  attend  the  CISA  Conference,  so  the 
definitions  presented  by  Brian  and  Jeff  are  new  to  me.  But  here  I  also  see  the  ambiguity 
of  the  term  “architecture”  causing  much  of  the  difficulty.  First  the  term  architecture 
integration  must  not  be  confused  with  the  DoDAF  term  of  integrated  architecture.  Here, 
as  defined,  architecture  integration  concerns  itself  with  standardization  of  terms 
[presumably  data  semantics,  data  and  metadata,  data  and  process  exchange  specifications, 
etc.]19  so  that  the  disparate  architecture  descriptions  “result  in  a  set  of  data  and  products 
[architecture  implementations ]  that  support  Joint  operations  and  development  efforts.”  So 
I  agree  with  Jeff  that  this  really  refers  to  the  systems  (i.e.  architecture  implementations) 
and  not  to  the  DoDAF  architecture  (i.e.  architecture  descriptions).  I  do  note  that  I  am  not 
comfortable  with  calling  this  architecture  integration,  because  the  term  “integration”  for 
many  people  carries  a  connotation  of  an  integrated  system.  For  me  the  goal  is  a  federation 
of  systems,  which  functions  as  if  the  enterprise  is  integrated,  but  allows  for  the  internal 
diversity  implied  by  federation. 


19  The  []  enclose  editorial  comments  by  the  author. 
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The  two  other  FJAWG  definitions  for  federated  architecture  and  disparate  architectures 
are  not  unreasonable  if  one  interprets  them  in  the  architecture  implementation  rather  than 
the  architecture  description  context. 

For  me  observing  the  BMMP  development  of  the  Business  Enterprise  Architecture 
(BEA),  a  DoDAF  compliant  enterprise  architecture,  in  which  a  high  level  OV6c  is 
designated  the  Enterprise  Business  Process  Model  (EPBM)  has  been  most  instructive. 

The  development  of  the  BEA,  including  the  development  of  many  of  the  essential 
DoDAF  views  at  some  detailed  level  has  been  enormously  valuable  in  guiding  the 
business  process  reengineering  (BPR)  across  all  of  the  Business  Enterprise  Priorities 
(BEPs).  But  no  one  should  expect  that  systems  (i.e.  architecture  implementations  —  or  as 
I  prefer,  instantiations)  acquired  by  the  Services/ Agencies  will  adhere  in  detail  to  the  “To 
Be”  DoDAF  architecture  descriptions .  Since,  whenever  possible,  one  wants  to  take 
advantage  of  state-of-the-art  COTS  and  extant  GOTS  products  which  provide  the 
required  functionality,  best  business  practices  will  usually  deliver  a  better  engineered  and 
tested  product  at  lower  cost  and  in  shorter  time.  The  PM  only  must  ensure  that  all  data, 
message  and  API  exchanges  outside  the  system  adhere  to  the  requirements  imposed  by 
the  federation.  The  “As  Built”  architecture  delivered  by  the  contractor  becomes  the 
repository  “As  Is”  DoDAF  architecture  description. 

Finally,  a  comment  concerning  the  DoDAF  lexicon  and  adherence  to  it.  Many  changes 
were  incorporated  during  the  more  than  ten  years  of  evolution  of  the  C4ISR  Architecture 
Framework  to  the  current  DoDAF  vl.O.  The  most  important  reason  for  developing  a 
formal  architecture  framework  is  to  be  able  to  readily  evolve  the  architecture  to 
accommodate  rapidly  changing  hardware  and  software  technology  and  equally  rapidly 
changing  requirements  —  or  if  you  prefer  capabilities.  Likewise  the  framework  itself 
must  also  evolve  to  accommodate  these  changes.  [Currently  the  WWW  is  undergoing 
enormous  changes,  as  is  the  Internet  itself,  for  just  these  same  reasons.]  Please  note  that 
there  is  not  a  single  mention20  in  the  DoDAF  of  federation  or  federated  (not  to  be 
confused  with  federal).  Certainly  it  is  time  to  evolve  the  DoDAF. 

And  in  this  regard,  I  turn  your  attention  to  the  “Reality”  (Slide  3)  of  the  Brian/Jeff 
FJAWG  presentation  at  the  CISA  Conference,  with  which  I  fully  agree,  reproduced  here 
for  your  convenience. 

“REALITY:  While  there  have  been  significant  advances  in  the  development  and 
use  of  architectures  in  recent  years,  the  Department  still  lacks  effective  processes 
and  governance  for  federating  and  integrating  disparate  architectures.” 

Those  of  us  trying  to  alleviate  these  problems  should  be  working  to  better  introduce  and 
disseminate  these  federation  ideas  into  the  broader  DoD  community  and  work  to  modify 
both  the  technical  and  policy  directives  so  that  we  can  change  this  unacceptable 
“Reality.” 


20  There  is  one  exception.  In  Volume  II,  Figure  5-30,  the  SV-8  evolution  has  a  Legacy  Mainframe  System 
evolving  over  five  years  to  a  Federated  Distributed  System.  Apart  from  this  diagram,  there  is  no  discussion 
of  this  federated  state  in  the  text. 
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Acronyms 


AA 

Approval  Authority 

ADD 

Assistant  Deputy  Director 

ADM 

Architecture  Development  Methodology 

AIT 

Architecture  Integration  Team 

API 

Application  Program  Interface 

ASD 

Assistant  Secretary  of  Defense 

ASD  (C3I) 

Assistant  Secretary  of  Defense  for  Command,  Control, 
Communications  and  Intelligence 

ASD  (Nil) 

Assistant  Secretary  of  Defense  (Networks  and  Information 
Integration) 

AT&L 

Acquisition,  Technology  &  Logistics 

BEA 

Business  Enterprise  Architecture 

BEIS 

Business  Enterprise  Information  Service 

BEP 

Business  Enterprise  Priority 

BES 

Business  Enterprise  Services 

BMA 

Business  Mission  Area 

BMMP 

Business  Management  Modernization  Program 

BMSI 

Business  Modernization  and  Systems  Integration 

BPM 

Business  Process  Model/Modeling 

BPR 

Business  Process  Reengineering 

BTA 

Business  Transformation  Agency 

BTP 

Business  Transformation  Plan 

C4ISR 

Command,  Control,  Communications,  Computers,  Intelligence. 
Surveillance,  and  Reconnaissance 

CAC 

Common  Access  Card 

CADE 

Collaborative  Architecture  Development  Environment 

CADM 

Core  Architecture  Data  Model 

CBM 

Core  Business  Mission 

CBMA 

Core  Business  Mission  Area 

CCB 

Configuration  Control  Board 

CIO 

Chief  Information  Officer 

CISA 

Certified  Information  Systems  Auditor 

CJCS 

Chairman  of  the  Joint  Chiefs  of  Staff 

101 


CJCSI 

Chairman  of  the  Joint  Chiefs  of  Staff  Instruction 

CM 

Configuration  Management 

COI 

Community  of  Interest 

CONOPS 

Concept  of  Operations 

COTS 

Commercial  Off-The-Shelf 

DARS 

Defense  Architecture  Repository  System 

DBSMC 

Defense  Business  Systems  Management  Committee 

DBT 

Defense  Business  Transformation 

DCD 

DFAS  Corporate  Database 

DCW 

DFAS  Corporate  Warehouse 

DECC 

Defense  Enterprise  Computing  Center 

DFAS 

Defense  Finance  and  Accounting  Service 

DISA 

Defense  Information  Systems  Agency 

DoD 

Department  of  Defense 

DODD 

Department  of  Defense  Directive 

DoDAF 

DoD  Architecture  Framework 

DUSD 

Deputy  Under  Secretary  of  Defense 

EA 

Enterprise  Architecture 

EBPM 

Enterprise  Business  Process  Model 

EIE 

Enterprise  Information  Environment 

ERP 

Enterprise  Resource  Planning 

ETP 

Enterprise  Transition  Plan 

FEA 

Federal  Enterprise  Architecture 

FIN 

Finance  Domain 

FJAWK 

Federated  Joint  Architecture  Working  Group 

FM 

Financial  Management  (Core  Business  Mission) 

FMMP 

Financial  Management  Modernization  Program 

GAO 

Government  Accountability  Office 

GIG 

Global  Information  Grid 

GOTS 

Government  Off-The-Shelf 

HRM 

Human  Resources  Management  (Core  Business  Mission) 

IA 

Information  Assurance 

IDA 

Institute  for  Defense  Analyses 

IRB 

Investment  Review  Board 
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IS 

Information  System 

IT 

Information  Technology 

IV&V 

Independent  Verification  and  Validation 

JCIDS 

Joint  Capabilities  Integration  and  Development  System 

JCS 

Joint  Chief  of  Staff 

KPP 

Key  Performance  Parameter 

LOG 

Logistics  (Domain) 

MOA 

Memorandum  of  Agreement 

NCES 

Net-Centric  Enterprise  Services 

NCID 

Net-Centric  Implementation  Documents 

NCOW 

Net-Centric  Operations  and  Warfare 

NDAA 

National  Defense  Authorization  Act 

Nil 

Networks  and  Information  Integration 

NR 

Net  Ready 

NSA 

National  Security  Agency 

NSS 

National  Security  System/Strategy 

O&M 

Operations  and  Maintenance 

OAGi 

Open  Application  Group 

OBT 

Office  of  Business  Transformation 

OMB 

Office  of  Management  and  Budget 

OSD 

Office  of  the  Secretary  of  Defense 

OSI 

Open  System  Interconnection 

OV 

Operational  View 

OV-1 

HighLevel  Operational  Concept  Description 

OV  -2 

Operational  Node  Connectivity  Description 

OV  -3 

Operational  Information  Exchange  Matrix 

OV  -4 

Organizational  Relationships  Chart 

OV  -5 

Operational  Activity  Node  Tree  and  Model 

OV  -6a 

Operational  Rules  Model 

OV  -6b 

Operational  Object/State  Transition  Diagram 

OV  -6c 

Operational  Event/Trace  Description 

OV  -7 

Logical  Data  Model 

OV-SV-TV 

Operational  View,  Systems  View,  Technical  Standards  View 
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P&R 

Personnel  and  Readiness 

PA&E 

Program  Analysis  and  Evaluation 

PDF 

Portable  Document  Format  (Adobe  Acrobat) 

PEO 

Program  Executive  Office 

PfM 

Portfolio  Management 

PM 

Program  Manger 

PPB&E 

Planning,  Programming,  Budgeting,  and  Execution 

PSA 

Principal  Staff  Assistant 

RM 

Reference  Model 

SecDef 

Secretary  of  Defense 

SFIS 

Standard  Financial  Information  Structure 

SLA 

Service  Level  Agreement 

SOA 

Service  Oriented  Architecture 

SOW 

Statement  of  Work 

SV 

Systems  View 

SV-1 

Systems  Interface  Description 

SV  -  2 

Systems  Communications  Description 

SV  -3 

Syste ms-Systems  Matrix 

SV  -4 

Systems  Functionality  Description 

SV  -5 

Operational  Activity  to  System  Function  Traceability  matrix 

SV  -6 

System  Information  (Data)  Exchange  matrix 

SV  -  7 

Systems  Performance  Parameter  Matrix 

SV  -8 

Systems  Evolution  Description 

SV  -9 

Systems  Technology  Forecast 

SV  -  10a 

Systems  Rules  Model 

SV  -  10b 

Systems  State  Transition  Description 

SV  -  10c 

Systems  Events/Trace  Descriptions  (Sequence  Diagrams) 

SV  -11 

Physical  Schema 

TP 

Transition  Plan/Planning 

TSO 

Transformation  Support  Office 

TV 

Technical  Standards  View 

TV  -1 

Technical  Standards  Profile 

TV  -2 

Technical  Standards  Forecast 
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UAO 

Unqualified  Audit  Opinion 

use 

United  States  Code 

USD 

Under  Secretary  of  Defense 

USD  (AT&L) 

Under  Secretary  of  Defense  for  Acquisition,  Technology,  and 
Logistics 

USD  (P&R) 

Under  Secretary  of  Defense  (Personnel  and  Readiness) 

USD  (C) 

Under  Secretary  of  Defense  (Comptroller) 

USG 

United  States  Government 

W3C 

World  Wide  Web  Consortium 

WBS 

Work  Breakdown  Structure 

WMA 

Warfighting  Mission  Area 

WTC 

World  Trade  Center 

WWW 
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